Yep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.)

I also feel unit-level tests are less necessary with TypeScript. I used to write a lot of JavaScript tests that essentially just confirmed that "this sh*t is all tied together correctly". With TypeScript, if a code change or refactor broke something structural, you know immediately!

> I also feel unit-level tests are less necessary with TypeScript.

Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is successful (and the compiler will nicely infer the type in subsequent usages once you do.)

For me, with rigorous compiler settings and a good proficiency in type modeling, I've reached the point where I rarely have any runtime errors at all once the code compiles. Sure it might take 2% more time to write code and think through my data model, but I spend 95% less time debugging it and the end result is much more maintainable. Even using typed languages like C# and Go now leaves me slightly dissatisfied!

Honestly, good integration of union's (Algebraic Data Types) is a good chunk of what makes Rust such a comfy programming language for personal projects. Being able to use a common, standard method to say "there may be a result or there may not, and if there is, here it is" is so expressive. Since the Option type is built into the language, it comes with lots of utility methods to make things even easier on me.

With C#, I am pretty sure you can get some of what you mentioned by using stricter compiler settings.

This doesn't come as a surprise to me, since Anders Heijlsberg, wo created TypeScript, was the technical lead of the team that developed C#.

I'm using TS for front/back end but you do need runtime checking as well at a few places, even though the compiler tells you it's redundant.

Relying strictly on typing is dangerous as you might've given wrong type from data coming back from database queries and you can't tell until it has run.

The major advantage of static types is replacing tests with proofs. Tests always have (limited) coverage, but type proofs are invariant. That said, it's very possible to misunderstand what a test or a type actually means.

> unimaginable

I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

I have never understood why typed languages make you slower at any point in time (early, late etc.).

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.

I completely agree with you, but the criticism isn't usually with typing number, it's typing complex higher-order functions or this kind of things. Where the time lost isn't in typing out the code, but in understanding what the type should be or (worse) what does this cryptic typing error means

I don’t tend to write or encounter many complex higher order functions in other languages. Are they common in JS?

It is not the typing per se. Anecdotally, I started adding types to my python code and it is somewhat useful.

That usefulness is diminished when you are fighting the type system instead of getting things done.

Like when you have to make exceptions in typescript by using Any. Like when an interface for a js library is missing and you don't want to do all that work.

Or when an API returns a field with a different type in between two calls and you have to make exceptions in the code when parsing with jackson in java.

Python’s type system is a particularly bad example. It’s not ergonomic and the type checking is immature.

Not sure what immature or ergonomic means in this context, but I'm pretty sure handling of "private" variables (self._foo) is abysmal.

Though you have a point, writing down type annotations can seriously slow you down when you are doing exploratory (prototyping) programming. It can also make your code less readable as the annotations can get in the way of the logic you really care about (easily fixed in an IDE, but people want to still use notepad to edit/read code). Then there is figuring out what the annotation should be in the first place, again easily enough automated in an IDE but the notepad problem remains.

What usually slows me down about dynamically typed code is you have some variable returned by a function only denoted by var myVariable = myFunction(); and I'm sitting there staring at thinking... "what are the contents of that variable? what properties do I have access to on that object? what can I do with it?"

And figuring that out becomes a massive time suck when that's a constant across an entire code base. Statically typed stuff means I can very quickly find that out even if it's the first time i'm exploring that particular area of the code.

I agree, in a type inferred language or a language where annotations can be supressed, this is just another matter of IDE affordable.

Some dynamically typed languages support type annotations that are only enforced dynamically; Julia is the primary example of such a language ATM.

A well designed dynamic language like clojure can have explosive velocity. Stuff just fits together smoothly: a predicate can be a function or a set or a map or a regex, but most importantly, libraries are built of these mutually compatible blocks. Reminds me of (Sussman's?) description of lisp codebases as organic.. of course, "explosive" can be very literal when type mistakes propagate and the data model goes to bizarroworld. In clojure, you can defend yourself with spec, which catches these things at the site of the mistake. It's a tradeoff I often like (velocity vs. compile time checks). It all depends on the domain.

Yes. Extra typing is not a huge drain, I agree, but it is a minor one. Shorter is better until it impacts readability. Visual noise is a thing.

Code is read much more often of course. You may argue you can read a fifteen-page book as fast as a ten-pager, but it's pretty clear that's not the case.

Of course tools and inference change the balance, but even so I avoid putting code into the the kiln until the design is fully understood and at least satisfactory. And that can take a few revisions.

You'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct.

Types don't slow me down, and I can't imagine working without them.

You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.

Also working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.

A mature refactor yes, a change in design often not.

> types as a first class construct

A wild Idris programmer appears

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation.

I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

I recently had to write a tool to output a Swagger file from a proprietary api testing format, and writing all the interfaces for Swagger based on the Swagger specification was hugely helpful. I’m not sure I would have been capable of completing the project without TypeScript.

Also coming from JavaScript development first, TypeScript made learning C# and templates a breeze.

What if the specification changes ? Being static is has both advantages and disadvantages. You can do the checks without running the code, but it doesn't guarantee run-time correctness. I think a better strategy is to type check the actual code via inference, maybe adding some doctype comments to help the static analyzer, then add run-time checks where things are likely to break. And you can make your API easier to use by checking the parameters, throwing helpful and descriptive errors, allowing several different types as input, so the user doesn't have to convert his/her model to your model.

The spec changing is the best part! (Or conversely, the worst part when you are 100% dynamic). You change your types to match the new spec (eg adding a case to a discriminated union) and you immediately get feedback on places in your code that are definitely wrong/incomplete now. It won’t find every change you need to make but it’s a big load off and frees up some cognitive capacity for what’s left.

TypeScript works reasonably well for this approach; it's how I tend to do things. It has some gaps when you want to do really advanced stuff, but it gives you tools like typecasting for crossing those gaps. One of the great benefits of JavaScript type systems is that since they're overlaid on a dynamic language, you can just "turn them off" as needed (when the type system fails to understand that what you're doing is safe). You can comment out type checking for a particular line, or even let your whole project successfully build while type errors remain. The type system then becomes purely a tool, and never a roadblock.

> design your system first just by writing the types,

Fine.

> look how it works,

Beutiful except it doesn't work yet because it's just types that make some shape. You could literally draw the thing with pen and paper.

> go bother with implementation.

And only then discover that something you have thought of as implementation detail is one of the main problems with your solution.

No problem. I'll just refactor some type. It's easy. Less beautiful but at least it'll work. Except it doesn't. Butchering your elegant design for hours you come to hard earned realisation that the shape you imagined that you wrote and carefully named all your types to represent actually has nothing to do with the one you need.

If you are a bad person you ship your mangled typed monstrosity that you just barely made to work with traces of your struggle fossilised for any future maintainers.

If you are a good person you toss everything to into trash (save for few hard earned implementations) and start fresh with knowledge and humility wishing you worked with TypeScript where you can start with implementation and only after you figured out the hard parts, add types that reflect your solution (finding few additional bugs in the process and getting more confident about the thing you wrote).

> You could literally draw the thing with pen and paper.

Paper does not tell you when something you draw is wrong.

> And only then discover that something you have thought of as implementation detail is one of the main problems with your solution.

What is no different from learning that something you implemented is wrong, except in that you spent less time to get the problem. Or do you expect some magical designing tool that will lead you to the right solution before you understand your problem?

> Paper does not tell you when something you draw is wrong.

With some things it does. At least better than your brain does. Typesystem does it even a bit better. But you end up with a picture not a program nonetheless, before you start writing implementation.

> What is no different from learning that something you implemented is wrong [...]

What is different is that with all the types you wrote, the process of problem discovery that happens during implementantion is stifled by what you wrote so far. Also you have additional temptation to contort your types and to leave it in a bad state because you wrote so much already and you'd very much want to avoid tossing that out.

My point is that you discover problem through experimentation and types make experimentation harder because they make the code in some ways harder to change. TypeScript avoids that by allowing you to use as much types as you want at any stage of problem/solution discovery but not forcing you to.

Well, again, what of the things you said do not apply to any form of planning?

The only benefit of a plan is that you may discover it's wrong, and it's easier to throw away than the done thing. If you are not willing to reform or throw away your plans, you are doing it wrong.

What you described is the waterfall approach, which brings so many problems in most real world software development scenarios.

The opposite of waterfall is not “no planning whatsoever”.

It doesn't as you've already made that decision when adding a property. Almost always you get rid of the property entirely and replace it with a new one (and the type), you extremely rarely change the type.

And you will almost always know what type a property needs to be. Name? string. IsActive? boolean. Last modified? Date. Etc.

Also typescript just has number, so you're not even faffing around thinking "int, float, long, double, decimal, unsigned, signed" when adding a number. Although this is ultimately a bad thing.

It does, I’m talking more about module/system architecture than properties. I might go through three designs on a brand new project and futzing with types and tests while factoring it is an inefficient use of time. Waiting until satisfied with design is my advantage.

Why do you imagine types slow velocity? My experience is the opposite. I occasionally prototype in Go and then backport to Python (to integrate with our application) because I can iterate so much more quickly (yes, Python has type annotations, but the ergonomics are poor and the type checker is immature).

Experience. Again, not talking about a mature project, but a new one in the design phase. Types (like unit tests) are extra work at this point until a good design is discovered. Which takes time to think about.

Wait, type checking is good again?

Suits me.

Welcome to 1985 folks :-)

Yes, but not the rigid ways of traditional typing but when using duck-typing.

Don't like pedantic attitude just because some recent paradigm matches that of a while ago. Back then, you don't know dynamic types won't be too welcomed.

Also apparently SQL is #good now. But only because all the people who just spent the last 6 years doing Node said so.

I'm also using it as my default. I also find it great that with every release, they are pushing features that promote immutability; ReadonlyArray, and const assertions, to make developer workflow better and safer.

> It doesn't slow down development

I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

> > It doesn't slow down development

> I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

I'm right there with you, I really don't understand this train of thought that catching errors faster somehow makes you slower. I like having the compiler there to catch my errors when I make them rather than some number of minutes/hours/days/months later when everything is on fire and I've forgotten the context of what I was doing.

Maybe learning a statically typed language (nearly) first damages your brain irreparably, and there's no longer any hope for me.

Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. Then you can commit to the days and weeks of refactoring at the end of which you once again have a program you can run.

Under dynamic typing, you just do a small part of the job, yet the program builds; you can get in there and try things. Decisions about how to proceed can be guided by errors you run into when you step on the things broken by the partial refactoring. Seeing things working right away can be a motivator to get the whole thing done. Or it can help you see that, oops, the change is not worth doing or bad for whatever reason: you dodged a bullet with a small amount of sunk cost (the few changes you made that you can throw away without a whole lot of regret).

Static typing helps with small refactoring where the ripple effect is small. The compiler pinpoins things that have to change; they happen to be few in number, and don't have too many ripple effects of their own. If your change breaks everything, then it's moot; the compiler tells you there are breaking changes everywhere.

There is another angle: under dynamic typing, changes can be done in ways that things continue to work. You can write modules that have "absolute genericity": they work with objects of any type without being recompiled. Such things are bullet-proof against all conceivable refactoring.

> Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right.

I’m reading this and I have just no idea what to say.

With static typing you don’t have to be very considerate in this work, because you will have a compiler telling you if anything is broken, not to mention refactoring-tools which can help you reliably and automatically make those changes across your entire code base in a verified 100% correct way.

With dynamic typing however, you just have to guess and pray.

Clearly static typing is the superior option in this specific scenario where you are calling out static typing to be a disadvantage.

So what am I missing?

I don't necessarily want the compiler diagnostics to go away; I just don't want them to prevent me from running the program.

A good language has a run-time type in every object, regardless of the type checking system, and allows programs to be run safely even if they are incompletely checked or if inconsistencies have been positively identified.

My pet theory is that it's proof of the Mandela Effect[0]... That or different people think differently and value different things. Nah, probably the Mandela Effect.

[0]: https://en.wikipedia.org/wiki/False_memory#Commonly_held_fal...

> Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. Then you can commit to the days and weeks of refactoring at the end of which you once again have a program you can run.

I have exactly the opposite experience here. If you're making a sweeping change to a core data structure, I would feel much more comfortable making a large change in a statically typed system. It would take much longer for me to feel comfortable releasing a change like that in a dynamically typed system.

> Under dynamic typing, you just do a small part of the job, yet the program builds; you can get in there and try things. Decisions about how to proceed can be guided by errors you run into when you step on the things broken by the partial refactoring. Seeing things working right away can be a motivator to get the whole thing done. Or it can help you see that, oops, the change is not worth doing or bad for whatever reason: you dodged a bullet with a small amount of sunk cost (the few changes you made that you can throw away without a whole lot of regret).

Is this how you work? That's terrifying. How much time do you have to spend poking and prodding after you make a change like that in order to be sure you've fixed everything? How much time do you spend tracking down the source of bugs caused by this weeks or months later?

> Static typing helps with small refactoring where the ripple effect is small. The compiler pinpoins things that have to change; they happen to be few in number, and don't have too many ripple effects of their own. If your change breaks everything, then it's moot; the compiler tells you there are breaking changes everywhere.

If your change breaks everything, it's too much to change at one time. Period. Smaller refactors that deliver some amount of value are so much faster than cleaning up for months after throwing caution to the wind.

To use the example of a change to a core data structure: If you want to make a breaking change to a given struct, the first place I'd look is to see if you can convert between the old style and the new style seamlessly.

If that's possible, then you copy the data structure, make your changes, and add a method on each to convert to the other. Then you can slowly roll out that new data structure to the rest of the application until the compiler allows you to delete the original. Speaking from experience this route is so much faster than swapping it out at the source, fixing it up everywhere, and hoping things continue to work as they should.

If it's not possible, not all is lost, but I'd need to see the specific example to give advice on what to do.

> There is another angle: under dynamic typing, changes can be done in ways that things continue to work. You can write modules that have "absolute genericity": they work with objects of any type without being recompiled.

If your code can work on literally any group of assorted types, but still do something of value, then I'm interested to see what it's doing. Sounds like it doesn't do much of anything except pass pointers around. Great for a collection struct, but that's about it. As soon as you need to get things out of it and do something of value, you'll need to have some idea what type you're getting back.

> Such things are bullet-proof against all conceivable refactoring.

I am extremely cynical of any promise regarding code that is "bullet-proof against all conceivable refactoring". OOP famously promised that for many years, but my experience has been that it's the cause of far more refactoring pain than it saves.

Hold on. Are you conflating OO languages with static typing? If your experience with static typing is Java then I actually think I understand where you're coming from now.

I find that the first 50 lines are faster / more immediate without types. By 500 lines it's largely even. By 5000 you will have to pry types off my cold dead hands.

I wish I could be convinced by the likes of Rich Hickey that types don't actually help, because he's so smart and charming and eloquent, but my experience screams the opposite.

Yeah, exactly. I think people add way too many zeros to those figures when they try to come up with advantages for dynamic-typing. There certainly are some, but I don't think agility is in dynamic-typing's favor.

The usual saying is that faster development is more important because your business probably won't get users anyways. As if Ruby is going to give you a two year head start before any chickens come home to roost.

I don't know about that. Maybe you will get a half-day head start on me if I'm using a statically-typed language I haven't used before and I'm digging through old projects to remember how to write my .gradle hello world.

Yeah, I haven’t used lisp enough, but I want to believe that there is something inherent in its simplicity that makes it categorically different from all of the other dynamically types languages I’ve tried which all would benefit from static types.

Hi, I'm from the rest of the world. I have successfully made small changes to a program which basically broke it, just to do a proof of some concept. I was able to run the thing and test the concept, while not stepping on broken things.

I don't want to commit to refactoring a large amount of code for the sake of a small change, just so that some code-writing robot gives me permission to run the whole thing.