Hacker News Reader

Comment by jongjong | Hacker News Reader

I don't know whose brilliant idea it was to turn TypeScript's type system into a Turing-complete language but now many developers are actually using it as such on real projects and it's a massive productivity drain and it makes some code impossible to read... Often, the IDE can't even display the type when you hover over the variable because it's too darn complicated.

Did anyone ever think "Hang on, maybe the problem, the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of? Oh, wait a minute, if the interfaces were really simple, would we even need TypeScript at all? Why don't we just design our software in such a way that the interfaces between components are simple so that we can easily remember which functions accept what kinds of input without losing our train of thought? Wait a minute, this idea already exists? It's called loose coupling and high cohesion. How in Alan Kay's name did I not think of it before???"

View on HN

If the Typescript team got carte blanche to create their own language, it would likely be... C#.

TS is complicated and chaotic because the language it compiles down to is. TS' aim is to model the behaviour seen in JS in a flexible, user-friendly type system. Good luck!

What doesn't make sense to me is when teams (like mine) have a blank slate and the choice of any mainstream backend language, and then opt in to that ecosystem anyway. TS is good when you're coming from JS sure, but some of us have used more "sane" languages like C# and Go :(

> If the Typescript team got carte blanche to create their own language, it would likely be... C#.

This is sarcasm, right? The creator of TS is the lead architect of C#

I feel like that’s supporting the parent, right?

Not really, because it's not a question of if TS creators got to make their own language.

And C# iterates at a rapid pace, with lots of language features being added, some of which would would not be possible in TS.

C# is in some ways less shackled by the runtime it has to target, while TS compiles away entirely. The CLR can be changed to suit .net/C# needs, and JS is not under their control.

I come from a Java / Kotlin background and TS is totally fine.

Some quirks I've noticed are typed objects not performing any validations, like for building DTOs. Structural typing so the newtype pattern is not possible without some awkward hacks. A general "disconnect" between compile time and run time behaviour, so once you start casting your errors are relegated to property access/usage time, which makes — IMO excessive — test coverage paramount in catching bugs wherever you have conditional logic.

I would have gone with C# or Kotlin if I had the luxury of choice, but I'll get that with a deliberate career move maybe.

If you’re taking in data from an external source that needs to be validated, I highly recommend a schema library like zod, that can produce a typescript type.

That way you can define the type in a single place, have runtime validation for that type, but also be able to use the type in typescript at compile time.

Can you use something like Zod with the newtype pattern? I use DDD-style types for domain specific data over primitives.

Go is sane? I just started using it and the parsing libraries all standardize tags and reflection.

Not exactly sane. Go is one of the most clunkiest awkward languages I've ever worked with. The only benefit is that it's somewhat easy to learn.

Go is sane for some definitions of the word! If I got to choose a language to work with though, it would definitely be Kotlin or C#, but I prefer Go over Python because there are fewer ways to solve problems, leading to generally simpler code.

It's like a modernised C but for web/infrastructure. Unfortunately ignores about 3 decades worth of progress in other languages, and is simplistic to a fault. Jumping into an unknown codebase is easier than every other language I've used as a result.

Go has it's time and place just like C. The developers chose to ignore that progress and created the C for distributed and parallelizeable code. Using go for what you use JavaScript for is like using C to do Java work. Sure you can do it, but it's not going to be easy and you're going to have a bad time.

As you've said, Go is sane by some definitions of the word but a user should know what types of sanity and insanity they are willing to work with and which are inherent to their problem space

This feels like an odd excuse moreso than a reason. Consider that most folks consider compiling software to go down to an assembly language. Which often has crazy semantics and intrinsics that many of us don't understand or know about.

I suspect what you mean is that they aren't just compiling down to JavaScript, but they are wanting to do so in a way that there is no foreign function interface (FFI) consideration for folks in either language. That is, largely to say, they don't want a Typescript runtime?

Precisely, TypeScript only exists at compile time. Half their goals relate to this fact, which leads to constraints regarding what the language can achieve.

> 3. Impose no runtime overhead on emitted programs. > 4. Emit clean, idiomatic, recognizable JavaScript code. > 7. Preserve runtime behavior of all JavaScript code. > 8. Use a consistent, fully erasable, structural type system.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I'm curious on reasons why not to build a new runtime. That it is hosted in javascript seems like something that shouldn't be that big of a deal.

> TS is complicated and chaotic because the language it compiles down to is

I hear this regularly but don't think it holds water. Other statically typed languages compile to any number of targets without issue; machine code, llvm, and even JS.

A goal of TypeScript was that it could be added incrementally to already existing JavaScript code. This meant it has to support a wide variety of crazy pattern used in already existing JavaScript frameworks and libraries.

If you want simple interfaces, just write simple interfaces. TypeScript does not prevent you from that. But it makes complex things possible, when you need it.

If you work with developers who like to make things needlessly complex, the solution is not to make the tools less powerful.

If you have freaky type-level metaprogramming in your project (even in a dependency) I think it just means people are playing around. Someone did that stuff for probably more for fun than to solve a real technical problem.

To be fair it’s fun to write ridiculous types to get ridiculously specific intellisense

Typescript is perfectly fine as a nice way to clarify what you're trying to write in Javascript - and it's much more pleasant, coming from more strictly typed languages, to deal with TS. But golf should only go so far. I draw the line somewhere around ternaries being used in type definitions. Like, shut up and actually write the function body, I'll figure out what it does.

>> but now many developers are actually using it as such on real projects

Seriously? That sounds like being bored and overpaid and/or not having enough pressure to make actual web and implement new features.

It's also bad because you have to, as a programmer, actually type out the types a lot (compared to say, Ocaml, Haskell or Rust), and like you say, it makes it impossible to read.

Personally, I don't get much value out of TypeScript based on how I structure my code. I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere... Then whenever I get warnings while doing this, it's always related to me messing up the type definitions themselves and not related to my code. It feels like the type system is the error-prone part and my code is the reliable part... Should be the reverse; types are supposed to help me write my code but I find that it's my code (simple interfaces) which help me write my types.

Type annotation work is definitely the annoying part which slows me down and breaks my train of thought.

That said, I don't dislike TypeScript in theory as a language if used carefully. It may just be worth the annotation effort (kind of like how comments are usually worth the time they take to write). I just don't think it's worth the additional transpilation step and all the compatibility and source mapping issues that come with it.

>I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere.... It feels like the type system is the error-prone part and my code is the reliable part

This is akin to throwing water over an oil pan fire, then being frustrated at the water for your house burning down.

You need to either use the Typescript way throughout your dev process, or not use Typescript. Both of those options are valid, but you're currently doing half of both, resulting in unnecessary frustrations.

I disagree, my point is that my code is better if I write it as JavaScript. TypeScript is more like an extra unnecessary thing I need to do which doesn't add any value.

A better metaphor would be; I want to boil some chicken and I have a pan full of boiling water... Then just as I'm about to put the chicken inside, the head chef stops me and tells me that I need to pour oil into the pan.

I protest; "But sir, there's no need, the customer asked for boiled chicken, not fried chicken..."

"Do as I say" says the head chef.

So I reluctantly pour a tiny bit of oil on top of the water, then I add the chicken. It splashes around a bit, no big issues, and the chicken comes out OK.

The customer got the boiled chicken they ordered, and they're satisfied.

"See, it all worked out... Aren't you glad you listened to me?" says the head chef.

In what ways would writing things the Typescript way make your code worse than the JavaScript way? I can't imagine the typing system preventing me from doing things that are better, other than cases where I want more expressive typing itself, which isn't even applicable to JavaScript.

This metaphor is all wrong. If we're going to stretch cooking, TypeScript is the recipe book. While cooking it seems you would prefer to write "add a bit of something savoury", when you really mean "1 tbsp Worcestershire". TypeScript's greatest strength is in the next person being able to pick up the component and being able to run with it, or you being able to replicate it again in three months.

If you start by just throwing all the crap you want into a pot and afterwards try to remember what you added and how long you cooked it for of course it's going to be a lot of extra work. TypeScript requires a methodical approach which over the long run makes it easier for the entire kitchen.

Completely valid - if you don't see value in a tool, don't use it.

But parent is saying that you should recognise that you're opting yourself in for a harder time by ignoring typescript at the beginning, and then trying to retrofit your way into type safety. That's definitely going to be more difficult and frustrating.

So either don't use typescript (which is fine fine - no one here cares about the programming language you use), or, use it 'properly' from the beginning and work with the tools you're using rather than against it.

Maybe your code is ok and understandable to you when you first write it, but when someone else has to work on it a month or two later, a lack of types makes it significantly more difficult.

It sounds like your process is a bit of a drag on you and I think you should improve it.

If you replace axe with chainsaw, you can’t expect it will perform better if you keep the same workflow of smashing the thing into the tree. To get the advantages you have to adjust your workflow, otherwise it will of course feel like an obstruction.

It's not the same because maintainable JavaScript code essentially always converts to maintainable TypeScript code. Adding type annotations to existing JavaScript code won't make it harder to maintain. However, maintainable TypeScript code will not necessarily convert to maintainable JavaScript code after removing the type annotations... Yet as well as TS can hide the tech debt and delay repayment thereof, it's still tech debt and you still have to pay interest on it.

Anti-patterns are the same in JS and TS; tight coupling and low cohesion is bad, complex interfaces are bad, unclear separation of concerns is bad, poor encapsulation is bad.

Whenever I've faced this problem (usually converting legacy JS to TS), it's because the original code was structured in a complex or unique way. Sometimes it's unavoidable, but for most code, refactoring it to make it simpler and easier to read also simplified the typing for the code

So maybe, TS working as intended

Also depends on your TS config probably, but TS does a pretty good job with inference, so I find that I don't need to write that many type annotations, especially when assigning variables

I agree with that but the way I see it is that if your JS code is bad, then you may get value out of TS, but if your JS code is already good, you won't get any value out of TS.

TypeScript is like training wheels on a bike. All good if your priority is not to fall, but if you want to compete in the Olympics, you may have different priorities.

Also, I think starting with JavaScript and migrating to TypeScript leads to much better code than just starting with TypeScript. I think the reason is because if you start with JavaScript, you naturally tend to avoid architectural complexity because it can quickly become unmanageable. So then when you add type annotations to existing JS code, you're not adding extra architectural complexity; just adding types.

When you start directly with TypeScript, it allows you to reason about much more complex interfaces so there is more temptation to over-engineer architecturally. Devs feel more free to invent all sorts of unnecessary abstractions which will come back to bite them later.

Spaghetti code is spaghetti code; you can label each noodle but it's still spaghetti.

> ... the way I see it is that if your JS code is bad, then you may get value out of TS, but if your JS code is already good, you won't get any value out of TS.

You might not get any value from the typing when writing the code, but the poor sod tasked with maintaining it two years later definitely will.

Also, the added types and compile time check will greatly benefit anyone trying to perform all but the most trivial of code refactoring.

Typescript adds some inertia initially, and you are correct in that it will allow inexperienced developers getting away with writing overly complex code, but it's definitely worth it for any code base larger than a couple thousand LoC.

It also lets experienced developers who are inexperienced with the code base become productive faster. It's a boon for anyone who hasn't been there since the start.

I would argue that if you are writing a lot of ‘any’ types before writing types that you a very likely doing Typescript wrong. The vast majority of you code (if not 100%) should ideally be statically typed at any given moment, right from the start. This does not mean though that you need to manually specify types everywhere - you can rely heavily on type inference.

My view is that if you feel the need to define a type up front, it may be because you're overusing it; it's being referenced by too many different functions. This often indicates poor separation of concerns between components (low cohesion) and tight coupling.

Good abstraction would imply that you're dealing with a different, more abstract type as you move up the component/dependency hierarchy. If the same type (especially a complex type) is present at many layers in your code hierarchy, it often means that the abstraction is leaky.

A common issue I often see is when devs try to pass a Logger instance to all components and sub-components in their app... Instead, why not just make all the components emit events (or invoke some kind of listeners/callbacks), then handle and log all the events at the root of the code in one place? This is a lot more flexible because then you can use any off-the-shelf generic component and it doesn't need to know about the existence of your Logger.

Also, it's a lot easier to read and maintain code if all the logging is invoked in one place. Logging is a single concern, so ideally, it should only affect a single component/source file.

It sure helps to know that something is an object or an array and thus intellisense can actually do something useful for you before you run in the bowser, or what an API returns, or a parameter `users` to a function is an array of users vs a Set of users, or that the the field on a `User` type went from companyName to organizationName.

Typescript is going to help you out greatly there. Nothing about any of that will slow you down, in fact it'll do the opposite. If you're leaving those all as `any` until the last minute I think you're really leaving a lot of productivity on the table.

> the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of?

Haven't brought this up in a while. Ya. I feel coding is hard due to complex interfaces. I once worked on a programming abstraction, mechanisms, aiming for a consistent interface for easy composition.

Key features of mechanisms were:

1) All data types were mechanisms

2) A Mechanism needed no context (parameters) when invoked.

3) Composition of a mechanism could take any number of mechanisms (primitives at this point are treated as mechanisms) and return a mechanism.

4) Upon invocation, a mechanism functions in one or more modes, returning either a primitive data type or another mechanism.

Think of it as currying or Lisp's S-expressions, but supercharged, envisioned as a base for Visual Programming Languages.

An example of composition using mechansisms:

// Compose

addTwo = print( map( add( 2, emitFromRange(0, 20, 4) ) ) );

Which is saying "Print a mapping of adding 2 to an emitted range from 0 to 20 by 4."

// Invoke

addTwo()

You're a lot smarter, and have significantly better memory than I do. Once an application has like beyond 10 different interfaces (whther data structures or function signatures) I simple cannot memorise them flawlessly.

Had you laid on the sarcasm a bit less thickly I might be more sympathetic but I'm not, Mr. smartest-person-in-the-room. Keep looking down on all the idiots who think they know more than you and wasted their lives producing blatant rubbish.

For those of a less elevated intellect, I think the answer is that becoming Turing Complete is actually a very low bar. Once you've got recursion and pattern matching I'm pretty sure it just drops out in the wash. "Type checking is unification" (some computer scientist or other, possibly Luca Cardelli)

> Why don't we just design our software in such a way that the interfaces between components are simple so that we can easily remember which functions accept what kinds of input

Good luck in defining 'simple'. For me, a simple function only accepts inputs which it knows how to handle, and performs no side effects. Bonus points if it always terminates. Personally I cannot maintain this level of simplicity without a type checker.

But on the plus side, you're still allowed to remember what your functions accept! The checker only kicks in if you get it wrong.

I think that’s a major simplification of what’s going on in software development. Alan Kay invented OO, and everyone says the same thing about OO - that it’s over complicated and slows down development.

And then everyone replies with, “well that’s not _real_ OO - if you did OO right the software would be perfect!”

Except real OO cannot be done.

So, yea types are a tool and should be used wisely. But let’s not pretend like there’s some magical methodology out there that removes complexity from software.

Functional programming does this. Probably not Haskell level ninja types or passing functions around like dependency injection, but the idea of separating state and io away from pure logic does indeed remove complexity.

Ironically the separation of state away from logic is why backend web development tends to be easier than say game development.

In my experience it's quite difficult to keep things simple. It's a constant battle and sometimes we fail.

If you are using typescript you can either go down the path of using `as` and `any`, which at that point the benefits start declining. Or you can work really hard with typescript and make something complicated that correctly matches your code's logic.

But saying, "write simple code" doesn't really help much without saying how to do it.

At some point someone needs to have the balls to create and push a better language than JS in the browser. It's a huge and scary undertaking, but until it happens we are firmly in transpile/good language -> WASM land for the foreseeable future.

TS is lauded, but I really think it's just the best of a bad bunch.

There's Dart.

But at the time, many complained of the lack of jQuery support and needing to transpile to support other browsers, so it didn't get the interest it deserved.

I don't think Dart is meaningfully better than JS (for some vague definition of better)

It provides opt-in type safety. Unlike TS, it's not a language extension.

LuaJIT?

There's absolutely no reason to push another language in the browser. Just make wasm your compile target. It's assembly for a reason.

Sure, if you're writing a lib...

If you're writing software and you're consuming libs and frameworks, a fragmented ecosystem sounds less than ideal.

Part of the problem that Typescript can help solve is that JavaScript can be tricky with undefined, null and accidentally casting numbers and strings to each other. It's really a godsend for very large web apps that have large teams of developers with more than 0% turnover.

ReScript solves this problem with a much much simpler type system and stronger inference at the cost of forcing you to handle nulls and undefined as Options.

I get that typescript's decision was to model js's behavior exactly in the type system. But now having seen the costs of that and how much can be gained by relatively small constraints on js I think it was a mistake.

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

- Brian Kernighan

So if I work hard to make a program really easy to debug, then I’m making it harder to debug?

I think the term "clever" is used to describe unnecessary complexity and indirection, which makes the code harder to debug.

I agree with the notion that simplicity is hard though.

Easy: I'll invest the same effort but for the double of time.

is your name Criss by any chance?

Reply on news.ycombinator.com