How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

https://chiragswadia.medium.com/how-an-anti-typescript-javascript-developer-like-me-became-a-typescript-fan-a4e043151ad7

by chiragswadia • 5 years ago

189 391 5 years ago

chiragswadia.medium.com

madeofpalk8• 5 years ago

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

kyranjamie• 5 years ago

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

uh_uh• 5 years ago

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.

airza2• 5 years ago

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

madeofpalk8• 5 years ago

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.

blacktriangle5• 5 years ago

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.

selfmodruntime6• 5 years ago

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

baybal22• 5 years ago

Yes, type checking do not require a new language.

mekoka2• 5 years ago

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.

ozim• 5 years ago

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.

ben5094• 5 years ago

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.

Zelphyr• 5 years ago

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.

myguysi• 5 years ago

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

watwut• 5 years ago

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.

irrational3• 5 years ago

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.

baron816• 5 years ago

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.

madeofpalk8• 5 years ago

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

selfmodruntime6• 5 years ago

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

kolme• 5 years ago

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.

cosmotic3• 5 years ago

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.

nickysielicki2• 5 years ago

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

madeofpalk8• 5 years ago

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

victorbojica• 5 years ago

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.

jdxcode4• 5 years ago

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.

nickysielicki2• 5 years ago

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.

lhorie3• 5 years ago

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.

jehlakj• 5 years ago

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

madeofpalk8• 5 years ago

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.

evmar2• 5 years ago

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.

damagednoob4• 5 years ago

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.

joshAg5• 5 years ago

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

prophesi• 5 years ago

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)

adverbly• 5 years ago

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.

kipple2• 5 years ago

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

ben5094• 5 years ago

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

chadlavi• 5 years ago

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.

_fullpint• 5 years ago

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.

pattrn• 5 years ago

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.

Orphis• 5 years ago

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.

kelnos4• 5 years ago

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

presentation• 5 years ago

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

diob• 5 years ago

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

winrid2• 5 years ago

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.

junon3• 5 years ago

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

fladrif• 5 years ago

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.

fendy3002• 5 years ago

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.

eyelidlessness7• 5 years ago

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.

cableshaft3• 5 years ago

For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing.

Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.

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.

And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.

oblio2• 5 years ago

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.

cableshaft3• 5 years ago

I agree, naming can be incredibly hard. I periodically spend a long time trying to decide the best name for variables, and at times whatever I come up with isn't satisfactory to me even then (and I usually try to explain it better in a comment at its declaration).

I don't always change the names if their use drifts a bit either because I know the other developers might be used to the code where it's named something else and it might confuse them, and/or I have to rename it in a bunch of places that might make a merge particularly messy, especially if I'm working in the same place that I think another dev might be working on at the same time (it's happened more often than you'd expect actually, I've had to do some particularly gnarly merges at times).

blacktriangle5• 5 years ago

This feels more like developers learning that any variation on Hungarian notation is a bad idea.

agumonkey3• 5 years ago

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.

gameswithgo2• 5 years ago

There are some languages that give you a bit of both worlds, like F#.

meheleventyone3• 5 years ago

Sort of but at the same time being forced to think about those things also helps get a handle on exactly those parts of the program. Remember you still need to think about them in a dynamically typed language but it's obfuscated because they're implicit.

cercatrova• 5 years ago

you have no idea what invariant or structure is required for the task

I often write the program in TypeScript types/interfaces first because it forces me to think about the data flow both in and out. In my opinion, data, not code, is the most important thing about a program.

munchbunny3• 5 years ago

you have no idea what invariant or structure is required for the task

In my experience, in general, if you don't already have an idea, you should probably be spending the up-front time thinking about it. If we're talking React/Redux, then carefully thinking through both data representation and what goes into components' properties/states helps a lot for designing a clean and understandable structure.

tshaddox• 5 years ago

Designing my types first is precisely how I want to begin prototyping.

zaccusl3• 5 years ago

There is why TypeScript IS so great.

In the early days of a new app or feature, you have no idea what the correct data/type shapes are.

In TypeScript you can define the types and then easily do major refactors even if you have 1000's of lines already written.

It becomes so tedious to do the same refactoring in JavaScript.

TypeScript makes it trivial to change an object or function signature when developing new code (or old code).

Refactors that take 3 minutes in TypeScript take 3 days in JavaScript and you better hope you catch all the uses.

The refactor ability that TypeScript gives you makes it so much easier to change data types and function signatures dozens of times until you get things right.

mentioal2• 5 years ago

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

ok123456• 5 years ago

The schema and functions are typed.

ogre_codes• 5 years ago

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.

strogonoff• 5 years ago

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.

pid_0• 5 years ago

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.

gamesbrainiac2• 5 years ago

I think a large part of the support for Typescript comes from being able to create good tools for the language.

But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.

It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".

This makes me feel very insecure about my code.

spyke112• 5 years ago

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.

gamesbrainiac2• 5 years ago

I can't comment on this, since I haven't really worked with JBoss, and haven't had to touch the .net stack in ages.

The python stack is pretty okay though. You just containerize it, and ship it. Some providers will even allow you to run containers as a function/lambda.

Octoth0rpe• 5 years ago

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

boring_twenties• 5 years ago

That's not the real Makefile, that would be the GNUMakefile. Also pretty simple, though.

seph-reed3• 5 years ago

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.

selfmodruntime6• 5 years ago

Why did you hate react? It‘s really one of the less complicated frameworks out there.

abraxas2• 5 years ago

Any reason you forged your own versus adopting Svelte or Alpine? As a fellow React hater I'd love your take on those lighter frameworks.

nothis• 5 years ago

"First I didn't like it because it takes longer to learn, then I discovered the obvious features that are the reason TypeScript was invented in the first place."

MatekCopatek2• 5 years ago

Don't want to oversimplify since the article has some useful insights, but overall it reads like a typical transition from thinking static typing is a burden to realizing type safety can be incredibly useful.

I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!

I.e. the newest language with the most everything is the best!

Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.

beaconstudios• 5 years ago

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.

disgrunt• 5 years ago

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

MatekCopatek2• 5 years ago

Interesting, I didn't know that! Guess I still have some of my youngster naivite :). But that's exactly how I felt - I remember the introductory programming courses being in Java, there was talk about switching to Python, but it only happened a few years after I was a student. Same with companies - Java was for "old corpos" and Python for "hip startups".

_fat_santa• 5 years ago

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

henearkr• 5 years ago

Not long ago I used to hate Javascript, and it was because I did not understand it very well, and then I read Flanagan's book "Javascript the definitive guide" and now I like it!

So, is there a good book that some of you would recommend, that would have the same impact as Flanagan's, but about TypeScript?

hocuspocus• 5 years ago

Are there big companies still doing untyped JS at scale out there?

I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing something?

jakub_g• 5 years ago

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

gcmeplz• 5 years ago

I loathed typescript at first because of the heavy compilation step, but setting it up to compile only when it was necessary (building for production), and to transpile the rest of the time (running tests, starting a server locally) made a huge difference for our team. A slow compilation step really is a huge cost!

lucasyvas• 5 years ago

While gaining popularity, JS + JSDoc is misguided and not a solution. The compiler is what is required to actually enforce standards within a team - otherwise what you have is a completely informal process.

I don't think type docs are useless - on the contrary, they are super helpful while migrating. But I think this trend is indicative of a different issue - what we are really seeing is more of a protest that JS needs native optional type support as soon as possible.

joquarky• 5 years ago

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

I'm a big fan of this as well. Webstorm also supports it.

It feels like the right balance to me, as it gives me a heads up when things don't match, but doesn't require that I go through the tedium that TS imposes once it touches a project.

speedgoose• 5 years ago

After being an early adopter of TypeScript, I decided to skip TypeScript in my next projects for a few years because I thought it was not worth the hassle. I remember spending a lot of time in DefinitelyTyped to create and fix type definitions, and when Babel and ES6 were popular I used that instead.

I recently changed my mind and started to migrate a large JavaScript codebase to TypeScript, in strict mode. I consider my team to be composed of only good developers but still, I found so many bugs. I still spend time on DefinitelyTyped definitions, but if you do more than prototyping or work on a project also developed with other people for more than a few weeks, TypeScript is for sure worth it in my opinion.

wwww4all• 5 years ago

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.

qwerty456127• 5 years ago

Although I like the actual language of TypeScript more than JavaScript, it still doesn't feel useful enough to justify its usage. Computers' native language is Assembly but we rarely use it and prefer to code in C/Python/whatever because this is so much easier (+ portable). Browsers' native language is JavaScript and it isn't much harder nor less powerful than TypeScript, nor does it provide a seriously different perspective (like Clojure/Elm/Reason do) so why not just use JavaScript (you have to understand it anyway)?

macspoofing4• 5 years ago

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.

cryptica6• 5 years ago

This is incorrect. This is just repeating popular rhetoric.

Well designed projects are broken up into manageable, individually testable modules... So codebase size is an anti-pattern to begin with. As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? What about having to type up all these extra type definitions? You could have spent that time writing more test cases.

adenozine• 5 years ago

I just can't bring myself to use curly bracket languages. I can't make a good enough case for any of them.

I read way too much code to make myself read code that's not beautiful.

shadowgovt• 5 years ago

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

tester34• 5 years ago

what are alternatives?

python's tabs?

recursive4• 5 years ago

lisp?

ben5094• 5 years ago

The major choices that avoid braces are indentation and keywords.

Indentation's upsides are less line noise. In my opion, while there's less noise, there's less symmetry, so it's a wash on the beauty count.

Indentation breaks many tools, especially the way amateur coders use them. They're frequently showing code snippets by copy-pasting into web pages that strip indentation.

Notably, the standard pylint rules insist on two lines between functions and classes because the extra whitespace helps people find things. That same whitespace you get if you close a function with a single brace...

Keywords are surprisingly nice. Lua does them very well:

    function foo()
        doSomeStuff
    end

You get rid of the pointless { at function, and you have a simple "end" when you're done.

jdxcode4• 5 years ago

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

badtakemaybe• 5 years ago

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

CraigJPerry• 5 years ago

> satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits

I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.

Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.

In typescript you could actually type concat in a meaningful way but i digress.

I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.

There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.

All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.

acemarke2• 5 years ago

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

matsemann• 5 years ago

While I'm fan of statically typing, there is something with Typescript I don't like, but don't know exactly what it is. In my day-to-day it's mostly Kotlin and Elm, which also are both statically typed, which I don't mind and mostly don't even notice.

But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? 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.

exhaze• 5 years ago

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”?

nobody02• 5 years ago

Elm and other ML-family languages have type inference, it does not ask a major part of human annoation of types while catches errors in compile time nonethelessly

jamil7• 5 years ago

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.

fimbulvetr• 5 years ago

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.

dep_b2• 5 years ago

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.

steenreem• 5 years ago

Here's an alternative to TypeScript that people who dislike type complexity but want better tooling, might find interesting: https://github.com/keyboardDrummer/typeless

Disclaimer: I'm the author

macspoofing4• 5 years ago

I like the post, but the author's original perspectives are something I was always perplexed by. There was a period in late 2000s and early 2010s where dynamic languages were all the range (Ruby, Python, CoffeScript) and static typic was seen as archaic and slow by an entire segment of development community and I never understood it.

I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.

I mean ... that is a perspective. EJB 2.0 was over-engineered for many use-cases. SOAP is an over-engineered standard for many use-cases. Static typing is not. 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.

also it felt slow to work on, as I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem.

Another interesting perspective. Every single one of those compilation errors was a runtime error waiting to bite you in the butt. If you think solving compilation errors is slow, debugging and solving runtime errors is way slower. I'm glad the author learned the value of compile-time checks.

The other reason was Advanced TypeScript concepts like Generics felt very hard to understand initially and I started feeling that I am in the Java world where every piece of code is strongly typed and overwhelming.

This right here is the big problem in a nutshell. There is nothing wrong with ignorance - we all start there. But it's one thing to be 'overwhelmed' by something when starting out, and another to being ANTI that something BECAUSE you don't understand it. The author admits he was overwhelmed by TypeScript and that caused him to be ANTI-Typescript. That is something you see in places. And that the author justified his Anti-Typescript perspective by having an ignorant view of Java to boot. The author talks about 'Java world', but does he have any experience with Java development at all?

symlinkk2• 5 years ago

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.

wmil3• 5 years ago

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.

macspoofing4• 5 years ago

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.

Uh huh. Are you trying to come up with scenarios that you think a typed language wouldn't be useful ... because you don't understand typed languages?

If you have to work with crap JSON blobs with arbitrary and inconsistent typing, static typing doesn't prevent you from treating it as a 'dynamic' untyped map. That's true of pretty much every typed language there is, from TypeScript, to Dart, to Java, to C#. I do a lot of JSON consuming in Java and Dart. My preference is to enforce a schema on the incoming JSON blob and parse it into a typed object automatically, but if I can't, then I just parse it to Map<?,?> OR List<?> and work on that level.

At some point you're going to have to write code to figure out the type of whatever property you're interested in because it may be important to know whether the property is a string, an int, a float, an array, or whatever.

But when you're in that situation static typing isn't solving your first problems.

Neither is dynamic typing. You're in the exact same boat in that case ... except you get the benefit of typing in the rest of your app.

mentioal2• 5 years ago

I have noticed a lot of people who grew up only using dynamic typing languages are discovering static typing for the first time and proclaiming it to be the "new way forward" or something. Kids...

antihero3• 5 years ago

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.

cryptica6• 5 years ago

They mean that people who have been back and forth multiple times over many years don't see the value in TypeScript. This is totally consistent with my 15 years of experience working on many different complex projects and having gone back and forth between JS and TS.

TS helps if the project is really poorly written... But that's not something to aspire to.

cryptica6• 5 years ago

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.

stupidcar• 5 years ago

Here's a project idea I'd really like to see: A version of Chromium, targeted at web developers, that is is modified to accept TypeScript syntax as a variant of JavaScript.

This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do.

This would let you use TypeScript without the need for any transformation pipeline in dev. You could then separately run TypeScript in a console to get async checking. Then only when you build for production do you run everything through a compiler/bundler to get a plain JS bundle that will work in everyone's browsers.

dep_b2• 5 years ago

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.

nobody02• 5 years ago

Typescript is boring, and boring is definitely something need to be treasured in the frontend world.

MFogleman• 5 years ago

This article echos the common complaint I've seen from people hesitant to adopt TS.

"I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem. "

Which is like saying, "I got rid of my carbon monoxide detector because it kept beeping at me"

mushishi• 5 years ago

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!

mouzogu• 5 years ago

I'm a senior developer and I've never touched TypeScript and don't have any desire to unless I have no choice.

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. Also I find it a bit verbose and ugly and I'm just not a fan of pseduo Javascript languages that need to be compiled down into JavaScript.

MentallyRetired• 5 years ago

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.

antihero3• 5 years ago

As another lead/senior dev, I've found that onboarding hires that know some TS into a TS codebase is a hugely slicker process than onboarding people into a pure JS codebase, simply because the typechecker can do the overhead of having to check each call etcetera.

The issues you are having sound like teething issues but as someone who's worked with TS for years I've found they aren't hugely difficult to overcome, either with @types packages, or writing declarations, or declaring module (and having an "unsafe" library that people use with care).

I don't use code hinting. In fact, I find it irritating.

I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind.

antihero3• 5 years ago

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?

Aldipower• 5 years ago

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

btbuildem2• 5 years ago

I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this:

  declare let myColor: Color | undefined;

Suddenly everything turned into Java with signatures cascading endlessly. I'm not blaming TS, it's more of a.. lack of faith to make the full jump? Or limitation of the underlying Javascript? This problem should be solved with having multiple function signatures, in the example above one with and one without the Color param.

I've been toying with Erlang for years, once I grokked how they flow control can be done via different method signatures, the Other Way started looking really inadequate.

gagege2• 5 years ago

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.

munchbunny3• 5 years ago

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.

zaccusl3• 5 years ago

TypeScript does have method overloading same as other typed languages (except you have to do runtime checks, but that is a JavaScript limitation).

jdxcode4• 5 years ago

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.

tomca32• 5 years ago

The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript.

It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.

btbuildem2• 5 years ago

Color | undefined; tells me that the dev who wrote the code doesn't know whether they will pass the parameter or not, it gets decided at runtime. Not only does this complicate the function signature, it inevitably adds a conditional inside that method -- or passes the buck down the line to another method called from within.

At that point, TS is just a burden.

jokethrowaway• 5 years ago

I had the opposite experience. I like languages with static types a lot and I used to be a fan of TypeScript.

After using it for a few OSS projects and professionally, I came to the conclusion that, if I need types, I'll use a real statically typed language if I need types and JS for what doesn't matter.

TypeScript works but: - it's a major pain to work with if your dependencies don't have type definitions - if another developer in your codebase left a hole somewhere you won't be able to rely on your types, you'll get runtime errors and you basically ruin the capability to reason around your code - it's slow (hopefully deno's efforts will bring some news in that regard)

TL;DR: TypeScript should be much stricter and don't compromise with JS.

gagege2• 5 years ago

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.

deckard13• 5 years ago

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.

cryptica6• 5 years ago

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!

DrFell2• 5 years ago

I have a theory that TypeScript was not actually invented for frontend developers, it was created for non-frontend developers who were forced to deal with the frontend, and hated JavaScript.

That's also why I think it's very funny that JavaScript developers are starting to use TypeScript on be backend, i.e. Deno.

You are using the patch to JavaScript that backend devs needed to make JavaScript more like backend languages in the very place that the languages it is trying to be like already exist. It's ludicrous.

SavantIdiot3• 5 years ago

Yes.

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

nerdkid93• 5 years ago

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

hckrnwsthrwwy• 5 years ago

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

DrFell2• 5 years ago

It's the extra layer of convolution. It's necessary in a browser, but when circled back to the server, it's vestigial.

With Deno, you're using a classic OOP inspired superset of JavaScript, transpiling it to JavaScript, and running it in a JavaScript engine on a server. That's only necessary in a browser.

On a server, if you don't want to use JavaScript, you can just directly use a classic OOP language, and dispense with the whole extra frontend transpilation abstraction.

Unless you're a frontend-only webdev, and, understandably enough, you don't want to learn a classic OOP language, which I believe is the real reason.

Or, at least I hope so, because the only other possible reason is mass obliviousness, and that's horrific.

SavantIdiot3• 5 years ago

Two downsides to TS: an extra step to transpile, and having to write shims when it bugs out and can't verify an external declaration.

Upsides? When tuned to its most pedantic settings I've uncovered a handful of bugs that would have otherwise launched.

That's worth far more than a few tiny annoyances. tslint > jslint.

SmellyPotato22• 5 years ago

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

hasmolo• 5 years ago

babel-node is also very nice, and more lenient about type checking. i've discovered nodemon with babel node gives me the ability to hack something together and adding a tsc build pipeline helps me correct the types when i'm done

SavantIdiot3• 5 years ago

Thanks for the node tip!

I built an electron webpack framework and it uses hot reloads, but since i fork a lot of processes, it doesn't quite understand those need to be reloaded too! Got a fix for that by any chance?

deckard13• 5 years ago

FYI, tslint is deprecated since 2019.

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

vergessenmir• 5 years ago

Not much said on the category of bugs caught by Typescript. That would have been an interesting discussion.

I dip between javascript and typescript and hesitate recommending it for large scale project for a large team as much as I would like to, coming from a background of typed languages on the backend. There appears to be a need for experienced senior typescripters on the team to prevent falling into certain traps and onboarding [1].

I do wonder though how he saw typing as over-engineering. It may cause intertia which he hints at in the next sentence but over-engineering is a bit uncharitable.

[1] https://medium.com/javascript-scene/the-typescript-tax-132ff...

robgibbons• 5 years ago

I often write Typescript and don't mind it; type safety is neat. But my personal take is that if I can't drop code into a webpage/console and have it execute immediately, it's not a "real" part of the web stack. It's a very useful abstraction for large projects, but it's still an abstraction from the actual syntax of the web.

johnday• 5 years ago

If anything, TS is a concretion of JS rather than an abstraction over it.

When you write TS, you are (literally) writing JS, except that you are also writing miniature contracts (types) which are shared between components of the system and between authors of the code. This helps to ensure that the JS everyone is writing is mutually compatible, and that pieces of JS that should fit together actually do.

The idea that something's not part of the web stack if you can't throw it at a browser seems a bit weak; especially as, in this case, you can throw a subset of what you write at a browser and have it perform as intended.

prussian• 5 years ago

Short article, felt like what has been said before numerous times. I will opine why I was hesitant at first. The biggest reason was I didn't want to start writing a bunch of not-js (as in not a "strict superset" of js) and also having to deal with writing my own type definitions. I remember trying things like flow and reasonml and got quickly annoyed bending over backwards to use non-reason/flow code.

It seems like as of 2021 though that typescript has sort of won and the community has done great work in covering virtually every package I seem to use. npm helpfully points out which libraries have typescript definitions or a @types/<package>. I'm still not entirely sold on the strengths of strong typing in terms of bug avoidance, but the IDE like features are enormous. For me personally I see typescript more as a forced, never stale or mostly-incorrect, JSDoc.

Blackthorn• 5 years ago

Still not a typescript fan here. It feels like a half-baked language because of the insistence of not having a runtime (even though some information makes it through to the underlying js...so this objection of theirs isn't total). In a usual typed language, you could extract the type of an intersection type using pattern matching. But you can't do that in typescript. Instead you get to pick the most relevant ugly hack for your situation.

Typescript feels like every one of its features has some catch, and it's very irritating.

boredpandas7772• 5 years ago

It takes a lot of mental and emotional capital in the creative process to produce something that is truly wonderful. Microsoft is systemically incapable of approaching creative perfection. Very few are.

mdoms5• 5 years ago

This is extremely unfair and rude. The TS language designer and lead developer is Anders Hejlsberg, who is also the chief architect of C# and Delphi. C# has been tremendously successful and, in my opinion, is truly wonderful as a general purpose language.

In the case of Typescript the team were working under very difficult constraints - the language must maintain strict compatibility with Javascript, and the output must be executable by a web browser that has never even heard of the language.

foobarian• 5 years ago

The issue that broke the camel's back for me was when I saw "cstomerName is not defined" in production. I just could not accept that it is OK to live with tools that let that happen.

elwell• 5 years ago

broke the camel's back for me was when I saw "cstomerName

Truly the camelcase's back...

tvphan• 5 years ago

Did you go back to using JS?

mdoms5• 5 years ago

I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.

I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.

As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

fallingknife• 5 years ago

I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."

bqmjjx0kac• 5 years ago

Yikes. The only way I could imagine this being okay is if N is bounded and small, or if the DB is SQLite.

mdoms5• 5 years ago

The term "premature optimization" has been weaponized in the industry at large. Especially in front end development. And it really, really shows.

jpgvm2• 5 years ago

JS the language isn't great but it's JS the culture that is the real problem.

There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore.

If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.

rovek• 5 years ago

JS the language isn't great but it's JS the culture that is the real problem.

This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni who have been given a loose understanding of React and unleashed on the world as "junior developers".

But maybe I'm just cynical.

29athrowaway2• 5 years ago

In the movie Minority Report, there is a scene where the protagonist is blindfolded and opens a fridge that contains one fresh and one spoiled version of each item.

Eventually, he bites a spoiled sandwich with mold and drinks spoiled milk.

That is the best analogy for npm.

radicalbyte• 5 years ago

It's the same thing with PHP (and Ruby). You can write reasonable code in it, the problem is that the engineering culture leaves a lot to be desired.

In Java, the engineering culture is strong but stagnant.

Python is toxic, it's full of scientists, the engineering is bad (but a little better than PHP because the community is of a higher calibre).

spideymans4• 5 years ago

JS the language isn't great but it's JS the culture that is the real problem.

I'm happy you bring this up. Us developers have a tendency to blame bad code on poor tooling/languages or on individual developers or organizations. Not enough attention is given to cultural factors within various ecosystems that systemically induce bad coding practices.

axguscbklp• 5 years ago

Much of web development doesn't need extreme levels of attention to safety. A good fraction of web development is such that errors are quickly caught in manual testing and at worst just make some button look weird for the short span of time before the problem is noticed and fixed. Also, time spent using generic safety tools is time that could instead be spent reworking and better understanding the specific code to make it safer. There is a lot of cultism in the industry about testing and type safety. I have seen people demand almost 100% test coverage for code that displayed some extremely simple UX which, if it broke, would be completely obviously broken the first time you tried actually interacting with it. I have seen TypeScript used for short code that basically just displays simple UX and is made up largely of calls to third party libraries anyway. I think there is no generic appropriate level of attention to safety. It depends on the context. If you're working on code that controls a spacecraft or a medical device, it makes sense to spend an enormous amount of thought and work on safety. For much of web development, that just doesn't make sense, but organizations seem to often fall into a trap of mandating bondage-and-discipline features for stuff that doesn't need it - why, I don't know. Maybe because there's an impression that "everyone else is doing it". I guess also, some people just enjoy it.

But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.

spideymans4• 5 years ago

I did one of my internships at a financial services company. Their web applications were responsible for performing transformations on massive JSON datasets, with a huge variety of financial data. This is precisely the kind of project that would benefit most from typing.

I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless.

We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs.

Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant.

Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so.

As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing.

As you said, this is utterly horrifying (especially for a financial services company dealing with real money).

lfxyz• 5 years ago

I've had a similar experience. My team is using Vue 2 and, while the VueX store is almost entirely correctly typed, inside the Vue components everything was typed as 'any'. There was no value being added in the slightest, but attempting to upgrade packages resulted in many new TypeScript and ESLint errors.

I ended up opening a PR to strip out TypeScript from all the Vue components so I could get things up to date (and ease a possible transition to Vue 3, which behaves much better with TypeScript).

I'm starting a new job soon and really hope I can work with React and TypeScript again.

polishdude20• 5 years ago

I have a personal project ive worked on a lot last year. There was a part in my code which at the time scared me a bit because of the complicated data organization and manipulation that was going on. When I first wrote it, I had to have a clear picture in my kind about what properties an object had and what their properties had and do on. I had to write this down all on paper.

This year, when I came back to the code. I converted everything to typescript. I made sure that every variable that my manipulation worked on had a type. It not only helped me remember how the code worked but it made it so much easier to understand it and modify it without fear of breaking things.

It's been super useful and I don't think I'll be writing any big programs in the future without it.

munificent4• 5 years ago

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head:

"... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared me ..."

The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.

specifying your types is about as low-hanging, basic a step as you can take.

No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that.

This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.

Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.

mdoms5• 5 years ago

They're saying that they found learning about types to be difficult and stressful

No, they're saying that types (which they don't understand) are "over-engineering". This is, frankly, not acceptable to me.

spideymans4• 5 years ago

The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.

I don't understand how one can be a great (or even half-decent) SWE with such an aversion to learning something so common and foundational as types.

spideymans4• 5 years ago

The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.

Respectfully, its really hard for me to wrap my head around this mindset.

When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the basic OOP lessons where they teach that a Dog is a type of Mammal which is a type of Animal, etc. Typing was ingrained in me before I wrote any meaningful code. So from my perspective (and the perspective of anyone who learned similarly), typing is basic, foundational knowledge, and programming without an understanding of types is akin to running before you can walk

I think a lot of the developers learning nowadays are learning to code only on JS. And on JS you can do a lot without ever thinking about types. So they get stuck in the mentality that typing isn't necessary, and don't ever put in the effort to learn types.

Learning about types isn't that hard. But if you've been conditioned into thinking that typing is esoteric (perhaps due to modern coding courses completely glazing over types), then you're likely going to find it very challenging.

rowanG0772• 5 years ago

This is wrong. Dynamically typed languages still have types that need to be understood by the developer. They are only checked at runtime and not at compile time.

akiselev5• 5 years ago

This comment and many others in this thread seem to be missing something.

I think they're also shoehorning their experiences. Some coders are cogs in giant tech companies that emphasize code quality, others are on teams in large business in an unrelated field, others are solo hobbyists, and still others are the only tech guys at their medium or small business. Some write code to run a business, others write code to probe the mysteries of the universe. Some write life or death firmware that'll survive for decades, others create landing or promo pages that will be deleted next month and are subject to the whims of the marketing department. Those are all vastly different contexts for a programmer and each requires its own set of trade offs vis a vis typing.

For example, I couldn't care less about strong vs weak or static vs dynamic typing at my current frontend job because the stakeholders don't know what they want, stuff changes rapidly, and there's little I can reuse from one request to the other but I was a full blown static typing crusader at my last job where I worked on a payment system that had to deal with schizophrenic regulations.

kelnos4• 5 years ago

Not the parent, but I think it's possible to simultaneously believe two things:

1) It is completely understandable that, considering how easy it is to for a new programmer to get started in a dynamically-typed language (and that those languages are pushed very hard as beginner-friendly), many developers have a hard time grasping the idea of static typing and how to apply it to code, because their mental model just never included that, and changing mental models is hard for everyone.

2) It is absolutely horrifying that this is the state of new-developer education (or the lack thereof) in our industry, and I would put this on the (long) list of reasons why software in general is so unreliable.

I give the OP a lot of credit for writing about his journey, and by doing so making himself vulnerable to criticism. And it makes me really happy that he was able to not only eventually see the benefits of typing, but concretely articulate some of the benefits he found helpful[0]. That, IMO, is a sign of a solid developer who is willing to expand his skills and change his mind when given new information. But from a structural standpoint, I wish he had better mentorship when he started out and had never fallen into the "typing is bad" camp in the first place.

[0] "Making impossible states impossible" is something that I sometimes still struggle to impress upon developers with years of experience under their belts. The compiler is there to help you and catch your mistakes before you even check in the code, if you give the type system enough information to do so.

neolog• 5 years ago

This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.

That's one key advantage of dynamic types, but it's not the only one.

Sophisticated dynamic type systems like Julia's are difficult to model statically. Some idioms would require dependent types if they're even possible at all.

mantap• 5 years ago

Around the world millions of people learn Java as their first programming language. It is not hard to learn how to use types or generics.

What appears to be difficult is to go from an untyped language to a statically typed one. Which is why everybody should start with a statically typed language so that the psychological barrier never develops.

eyelidlessness7• 5 years ago

a very admirable job explaining what's going on in their head

As someone who followed the author's path, this is spot on, and also what I recognized in the article. Everything else you said is spot on too, I just wanted to call this out as part of the article's would-be audience.

svachalek• 5 years ago

That's true to a point but it depends on perspective. On a big team with a mix of experience levels, you are going to want to put up as many barriers to mistakes as possible and it doesn't matter how much it slows anyone down because it can't be more than dealing with the problems will be.

But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.

aeturnum• 5 years ago

I think one of the sources of this kind of attitude is experience with type systems that are clumsy or slow to use. This goes equally for languages without type declarations and those with.

Personally, the two things I informally look for are:

* Does the language allow instant-to-a-human static analysis so I can see warnings when I'm passing the wrong type to a call?

* Will this language allow me to leave sections (almost always something I get off the wire) with minimal / no type information in order to come back to it later?

Typing is hugely powerful for avoiding problems. I've done a lot of work in Python, which I think has missed huge opportunities to introduce a more robust type-checking system. My current favorite is Elixir / Erlang, which I think uses pattern matching and static analysis to balance strong typing v.s. weak typing wins. It's interesting to compare Elixir to Elm. Elm has a much stronger type system, which means I almost never pass the wrong thing, but it also makes dealing with unstructured data much more frustrating.

mekoka2• 5 years ago

As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take.

How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?

If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

"Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.

luuio• 5 years ago

there have been many languages whose success was specifically tied to the fact that they were dynamically typed

Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.

lmm5• 5 years ago

How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?

The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.

eyelidlessness7• 5 years ago

How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?

How do you come to the pain point conclusion about static types, rather than prior art static type systems, when the vast majority of tooling around the most popular dynamically typed language explicitly dedicates resources and visibility to its most popular static type system?

throwaway894345• 5 years ago

I've worked with a lot of people in the Python world who just wanted to move tickets across the kanban board as fast as possible, and they'd do a quick check of the happy path and call it a ticket. They'd be praised for their output and we (rightly, I think) didn't try to trace bugs back to a developer. They would do all sorts of dynamic-typing hacks to get the immediate task at hand done with little regard for the mess that was made, and they strongly disliked static types because they made those error prone, unmaintainable hacks really difficult to express.

Let me pull that out into a block quote:

[types] made those error prone, unmaintainable hacks really difficult to express

This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.

ChrisRR• 5 years ago

As a c developer, I've always found the lack of typing to be one of the things I dislike about python.

If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation

In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation

Adding types gives you so much more information in so few characters

lmm5• 5 years ago

What C has barely counts as typing, frankly. No generics, no polymorphism at all, no sum types, even basic wrapper types are painful...

pbreit2• 5 years ago

Types make little sense to me. I guess I'm not welcome in your world.

eyelidlessness7• 5 years ago

Types do make sense to me, but they didn't always. You're certainly welcome in my world. You're also welcome to reach out if you want to gab and learn a little about how learning static types has improved my engineering life and skills. Easy to find contact from my profile.

nicbou2• 5 years ago

Types loudly state what you accept, and what you return, and possibly enforces it.

The real world equivalent is giving plugs specific shapes, so that you don't plug your headphones into a 240V wall socket.

In a large enough team, this is essential to prevent incorrect data from being passed around, and breaking further down the line after causing a lot of damage.

andrew_2• 5 years ago

"horrifying" is horribly melodramatic. perhaps sigh-worthy, but let's stop short of sensationalism.

eyelidlessness7• 5 years ago

Oh come on, this is a discussion probably older than both of us put together. And we probably both know that the discussion devolves into where/what kind of tests are written. I'm on your side in the static type system debate, but you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.

eropple4• 5 years ago

you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.

I certainly realize it, and I've seen it once in ten years and it'd have been dealt with automatically by a compiler because they were writing tests for autogenerated code. (Why not test the generator, you may ask - and that's a story for another day.)

nromiun• 5 years ago

If a majority of software developers had your attitude towards static types all dynamic typed languages (maybe except for JS) would have died out by now.

If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.

jimmont• 5 years ago

Interesting characterizing engineering as honestly, horrifying, low-hanging and regarding one approach to typing as translatable to all practices and the underlying assumption it conveys a guarantee of reliability. I don't find any of those things to be true (in isolation or together). Of course I only know so much so there's that.

nicbou2• 5 years ago

Typing offers guarantees. You can guarantee that your function will receive the right inputs, and produce the right outputs. Even soft typing enforced by an IDE is beneficial in that sense.

I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along.

A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class.

In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things.

If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.

coldtea• 5 years ago

There's nothing especially "horrifying" about this.

In fact, several geniuses in Computer Science have historically been of the same opinion (pro dynamic typing).

trixrabbit• 5 years ago

I've been using typescript for years and one complaint I have is that it hides really powerful features of prototype based programming and make javascript look like a normal class based language.

danielrhodes• 5 years ago

The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the types also improves your productivity.

The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.

Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.

Barrin92• 5 years ago

I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp.

Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it does based on the type signature. He didn't know. I didn't know either. Int -> Int -> Foo -> String -> Foo very quickly starts to mean nothing.

Types don't enhance the meaning of the code. if you want to understand your code better, what you're looking for is better names, not better types. As far as understanding code is concerned, in the best case types have the exact function as names, in the worst case they entice people to write 'int x' rather than giving something a proper name.

selfmodruntime6• 5 years ago

The magic is in the combination of types and proper names. What use is a variable that‘s nicely named when you don‘t know what it holds?

resonantjacket53• 5 years ago

If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.

tome• 5 years ago

Huh? Just because there was once a function whose argument types didn't help you understand it doesn't imply that types aren't an aid to readability in general!

drazulay• 5 years ago

For me it was "How a repl hater became a Julia lover..."

Multiple Dispatch, I love it.

Tade0• 5 years ago

My aha moment with TypeScript was when I realized that, in spirit, it's the same thing as ActionScript - a superset of ECMAScript with a stricter type discipline.

I had no issues with that back when I was a teenager trying to put together flash games, so apparently the only thing preventing me from writing exclusively in TypeScript was a lack of a decent toolchain.

BluSyn• 5 years ago

My problem with TypeScript is the lack of runtime benefits. Yes, you get some benefits of static checks during compile time, but at the cost of huge additional effort. This effort maybe makes sense for a large project with many team members pushing code, but for small hobby projects I think this just makes quick iteration far more difficult. To me this defeats the whole purpose of using a dynamic garbage-collected language to begin with.

If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.

As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.

h1fra• 5 years ago

Currently maintaining a very large codebase in TS, and never going back to vanilla. The initial migration found hundreds of bugs, typos, imperfections. And now every refacto, bugfix, new features... can be trusted.

More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.

Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration. It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.

throwaway4good• 5 years ago

I like you can type check stuff like this:

   type State = { id: "initial" } | { id: "running", speed: number }

   const f = (s: State) => {
     switch (s.id) {
       case "initial": // s.id available
         break;
       case "running": // s.id and s.speed available
         break;
     }
   }

The problem with Typescript shows up when people with background in Java or C# starts taking oo design patterns into js-land where they don't really belong (patterns like dependency injection, factories, singletons etc.).

ilaksh• 5 years ago

TypeScript feels like a kludge and requires giving up some of the useful aspects of JavaScript.

I feel that things like using WebAssembly to bring in other languages, or compiling down Ocaml/Ocaml-like languages such as with BuckleScript or Reason etc. is more appealing than TypeScript to me.

toolslive2• 5 years ago

TypeScript is definitely an improvement over pure Javascript. However, you can still lie about the types and it still allows you to write nonsense (even in pure TS).

  >   const x = 'xxxx'
  >   if(x === undefined) {
  >       console.log('never happens')
  >   }

will compile without any problems

mschuetz• 5 years ago

That example looks like a strawman to me. In practice, x would probably originate from outside the function, as a parameter or class member, and there is a good chance it could hold the value null or undefined. Seems like way too much additional work with little to no benefit to make the compiler track things like that through the whole application. Worse, the variable state could intentionally be hardcoded to try things and it would be weird if the compiler would error because the variable is never set to undefined, when I might be hardcoding it to undefined later on.

curtisf• 5 years ago

TypeScript _does_ detect some such impossible conditions (like `x === 1`), so this omission is intentional.

I think this is partly necessitated by one particularly large soundness hole in TypeScript, which is that expressions are typed as though dictionary and array subscripts are always in bounds:

    function foo(arr: number[]) {
        const m: number = arr[3]; // typechecks
        if (m === undefined) {
            // this IS reachable
            console.log("arr does not contain key `[3]`");
        }
    }

The alternative would be forcing all array and record accesses to have type `whatever | undefined`, despite the fact that almost all such accesses are clearly in bounds.

This is in fact now a part of TypeScript behind a flag since 4.1: https://devblogs.microsoft.com/typescript/announcing-typescr...

Adding a compile-time bounds-checker to TypeScript to find cases where the `| undefined` is unnecessary would definitely be helpful and interesting, but would do nothing to help TypeScript's reputation of being difficult to wield and slow to compile.

It's also not an easy problem to solve, due to the semantics of JavaScript arrays:

    let a = [];
    a[5] = "five";
    console.log(a.length); // 6
    console.log(a[4]); // undefined (!)

toolslive2• 5 years ago

you're right about the dictionary lookup possibly being undefined (and the compiler flag there). Some people (including me) would really appreciate a `--hindley-milner-type-inference` compiler flag.

bcheung• 5 years ago

I have a love hate relationship with Typescript. I have come to see it as a tool and to use it when it makes sense and avoid it when it doesn't.

I like the language at a conceptual level and find what it does very useful. The syntax I find less than desirable (especially nested generics).

For smaller projects I tend to use just JS because it's faster if I just want to prototype an idea and I'm not planning on keeping the code around for long.

Where Typescript shines is when working with a team on longer term projects.

The generic syntax gets derives from C++ which I don't think is a very good syntax. When dealing with more complex generic type declarations with nested generics / types your eye is scanning back and forth trying to match angle brackets and it is really hard to parse visually. Other languages like Haskell allow you to just read the "generics" left to right. Aliasing the type helps to some degree.

The other thing I don't like is when you are experimenting and fleshing out an idea you want to take a try it and see approach but with Typescript you have to really commit even though you just want to experiment. When you want to change something there is so much more code that you have to change.

The pros are when dealing with code you wrote in the past and forgot about what the types / parameters are or when dealing with code written by other people. Having the IDE suggest what you need to pass it is amazing.

The contrast to that is having to jump to a function to see what POJO style object it will return, what the exact spelling of the property / key are, and things like that. Having static typing saves so much time when dealing with other code.

If your project involves you working with others' code or code you wrote in the past and don't remember well then this is Typescript's sweet spot and it is a huge win.

One of the things I find most lacking in Typescript is pattern matching. If you have strong static typing like Typescript does then pattern matching pairs really well with that. It makes your code much more declarative and easier to read / write.

frenchy• 5 years ago

The other thing I don't like is when you are experimenting and fleshing out an idea you want to take a try it and see approach but with Typescript you have to really commit even though you just want to experiment. When you want to change something there is so much more code that you have to change.

I've seen this opinion before, and I don't understand it in the slightest.

Let's say you're modeling a "user". You might initially think that users should have a first & last name, so you write it this way. Then later on you realize that there's no point in this distinction, and some of your users from Indonesia don't even have separate first & last names, so you want to switch to a single name.

* With weak/no typing, you have search around for anything that matches the field names, and hope to God you didn't miss anything.

* With stronger typing you just change it let the compiler tell you all the places you need to fix up.

29athrowaway2• 5 years ago

Verifying types is something computers can do faster and more reliably.

By removing type annotations you are going against automation. And, as a software developer, automation is your job.

yboris• 5 years ago

Mildly-related project I have: generate call graph for typescript files

https://github.com/whyboris/TypeScript-Call-Graph

The TypeScript language service is really neat -- you can use it to parse through .ts files so you can, for example, see which functions call which functions.

kgin• 5 years ago

It's a lot of extra stuff on the screen to help sometimes find a very specific type of bug in a different way than you would have found it otherwise.

bengalister• 5 years ago

Not sure if I am a Typescript fan but I would most of the time choose Typescript over Javascript most of the time for frontend or backend NodeJs development.

I used to think the same. Coming from the Java world (might explain why I like it) colleagues convinced me that it would be better to use another runtime (JVM/CLR) than trying to use types on NodeJs (it was stupid). I used Typescript in the first versions it was painful, trying to find type definitions, writing my owns, etc. So I did not insist and moved to Javascript for NodeJs.

I rediscovered the language 1 year ago and uses it for some frontend (Vue) and backend (api gateway, lambda, mongoDB/dynamoDB) Nowadays I very much like the language, union and intersection types make it very expressive and precise. Compilation (or translation) is a little slow but bearable, and it is nice to have a common language and tooling between the frontend and backend. Most of the libraries provide and maintain typescript definition files when they are not themselves written in Typescript. Sometimes I think the language goes too far in the features, I had a look at the latest versions and was a little bit puzzled by the complexity. But even for small projects to larger ones, I definitely prefer statically typed languages (with type inference and even implicit ones) especially when time is limited to write tests and have a good test coverage.

vermilingua• 5 years ago

As a relatively fresh "JavaScript developer", how do I make the transition to TS? How do I convert existing projects, including React projects, and configure npm to run smoothly with TS?

Is there some authoritative guide on this?

skilesare• 5 years ago

I want a coffeescript that lets me define types when I want to, but doesn't require it. Thanks.

abraxas2• 5 years ago

Typescript + NodeJS + React + Server Side Rendering yeah... I love my young colleagues, I really do. I enjoy their infectious enthusiasm and only quietly discreetly in the secrecy of my mind recall how we built strongly typed JSP sites that did more or less the same thing 20 years ago. But in those days we got excited by Struts, Tomcat and JMS.

Verily there is little new under the webdev sun...

resonantjacket53• 5 years ago

Your comment reminded me about the html over websockets article a couple days ago https://news.ycombinator.com/item?id=26265999, though the general consensus seemed to be against it.

Yeah it is quite interesting how everything goes in cycles.

andrew_2• 5 years ago

Came from a statically typed background when I landed with JavaScript and - absolutely loved - the fact that it wasn't. I've been using TypeScript for the better part of four years for my day job, but I'll still use plain old JavaScript when the situation allows for it. TypeScript has become a religion, and I've seen folks screaming in Github issues because a 14 line package didn't export types.

TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.

cryptica6• 5 years ago

> However, when I moved to my current role, working on JavaScript was not a choice, as all the apps I was going to work on, were written in TypeScript

Classic stockholm syndrome. It sucks but I have to use it to survive so now I love it.

> Making impossible states impossible

Well if they're already impossible, there is no need to make them impossible.

> exhaustive checks

There is no such thing in coding. You can never exhaustively check all possible issues.

> Spotting bugs early

How about learning to write good tests?

> Rich IDE support and ease of refactoring

Yes, TS makes it much easier to write and refactor spaghetti code with low cohesion and tight coupling. If you have clean code with good separation of concerns, it makes no difference to the refactoring experience at all if you're using TS or JS. Why TS developers always talk about refactorings? If you need to 'refactor' your code, it means you designed it wrong. Perhaps TypeScript encourages over-engineering which necessitates constant refactoring?

wmil3• 5 years ago

One problem I have with TypeScript -- the syntax for functions that take and/or return functions seems messier than it should be.

I wonder if I'm missing a better way to do it.

sholladay• 5 years ago

My issue with TypeScript is that it simultaneously has some complex features that result in types that are hard to follow and yet it also lacks simple abilities like creating a type for a number within a certain range. I end up wanting to use Joi to further validate the types, not because I need runtime validation, but just because it's significantly more thorough and in some cases easier to read, too. But then I end up with a lot of duplication between Joi and TypeScript. It holds a lot of promise but there's too much friction there.

panzerklein• 5 years ago

Supporting static range types is crazy hard. Only full-on math languages like Idris can do that. If you need runtime checks and types without duplication use something later like zod or io-ts. They can derive ts types automatically

wildpeaks• 5 years ago

This is why I miss AS3/Flash: it was a great first language for people to learn programming because it was easy to approach like HTML/JS, yet had types to teach good habits from the start.

If anything, Typescript is the best of both typed and dynamic languages because you have the option to use types only in places where you really want to enforce them, it's not all or nothing.

How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

Related Stories