After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it.
So as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case.
I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. They don’t. They just become implicit. It takes something a computer is really good at, and shoves it into your brain. And as many point out: the types are, more than anything, documentation.
But beyond any of that (and I feel this is the most important lesson): when there’s like a 100:1 ratio in favour of something, you’re probably wrong. Not always. But probably. And it’s your ball. You can take it and go home if you want. People can fork. But sometimes you need to, at best, say, “I simply do not understand you people, but you’re the overwhelming majority, so whether I like it or not, I need to leave things as-is.”
Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there.
Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.
> Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there.
I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
One advantage of going to JsDoc type annotations for some libraries is that you don't need to deal with sourcemaps. People can use the source code as-is and they can bundle and minify it if they like.
That doesn't seem to be what this is about, though.
> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it.
TS isn't an extra layer of complexity.
Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity.
Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity.
Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity.
Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity.
Typescript makes you pay up front to remove a LOT of complexity down the line.
I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all.
TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't.
I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types.
OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere.
Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
I could copy and paste JS code into a REPL/browser console to find bugs/REPL-basee development, but that won't work for Typescript. Debuggers take some more time to set up too. More complex than other typed OOP languages like C# or Java which don't have these steps.
I got sick and tired of running code in the debugger just so I could see what fields an object even has.
Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever.
Just, like, no.
Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
… and that's why decades of work went into things like making better debugging and analysis tools, things like symbol files, etc. One of the appeals of the web was that you didn't need to deal with that but using a compiler of some sort makes that necessary again. It mostly works, most of the time, but it's never been that hard to run into some case where it doesn't. I don't think it's a deal breaker but I do consider it legitimate for someone to say they don't get enough benefit to be worth it.
Modern web requires compiler/bundler/minimizer for js code any way, whether you use typescript or not. And this will probably never change. Rather, the web will move to use of something like webassembly.
That’s not true in general: the modern web is quite capable with native browser functionality and many apps don’t need more. Tools like React do but that’s because they’re designed around IE6, which was a very different era.
Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision".
If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
What I found ironic was this part from the reasoning post:
> [V]ery few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
I mean it’s also simply not true. Most JS developers who have been doing JS for at least ten years have explicitly gone from not caring that much about types to being thankful for them.
To be fair, open source is not a democracy. The project owners/authors/maintainers can do things because they feel like it or prefer it, without having to justify it to anyone - even if everyone else openly hates it and the project loses users or contributors as a result.
Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it.
Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement.
Remove TypeScript, change linting rules, remove Prettier, breaks all PRs ... seemingly with no discussion and merged within 2 hours of the PR.
Sounds like a project I'd stay away from.
With comments like "Also, TypeScript hurts to write. Good riddance."
What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transpiler) step on the front-end simply too much to ask?
I say this as a lead on an enterprise Angular project who used to loathe front-end development (for 20+ years). TypeScript has brought back some sanity.
I grew up on JavaScript and usually enjoy it, and also adopted TypeScript and usually get along with it.
I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.
> But, I don't know that it's ever truly helped me move faster
It's incredibly helpful to move fast on large projects.
It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.
I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.
Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.
Ya that's sort of what I meant by the rest of the comment, and I agree, in theory, but haven't personally encountered this because I've never come onto a project that's already had a well-established TS implementation. I'm always doing the implementation, and then lose my job before getting to the point where the benefits were realized, and it's quite a slow path to getting to a place where the full codebase of sufficient size is typed, simply because most huge cosebases have evolved over time and aren't completely JS or TS.
Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.
I've had to deal with a couple other unilateral decisions that DHH drove into the Rails ecosystem (e.g. getting rid of Webpacker) and I think that staying away from his projects is a good idea.
I just can’t imagine an organisation taking a project that has DHH part of it seriously. You’d never know whether something you’ve vested engineering time into might just all of sudden just do a huge 180 and decide the tool your using should completely change
On the contrary. Most Rails apps with Turbo and Stimulus enabled only need a sprinkle of JS. It's so minuscule that you don't even need an IDE, even less TS either on the client or the library side. Thus, this PR both makes sense and most users won't even notice something changed. So the reasoning is good.
I see much hate on DHH for doing this, but I sincerely support him on many levels. And I am glad someone was bold enough to do this so publicly. Go team JS!
I've written maybe a couple thousand lines of TypeScript. I'm an utter neophyte there. I didn't hate the experience, though.
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
> I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
I can relate to this when it comes to Python. Type annotations & mypy have undeniably caught bugs and forced me to write better & more correct Python. However, it's also true that I've felt a lot of frustration with them at times when I was nagged about something that was impossible, and fixing the mypy error felt like makework that didn't actually improve anything. I'd argue the result in those cases was worse.
So is it worth it in the end? Probably, and I'd use them in personal projects and run mypy as well, but I feel that the Python community could be taking it too far. Type annotations were supposed to be gradual opt in (and they still can be), but nowadays it doesn't feel that way, and while I appreciate the benefits brought by using them, I can't help lamenting what I see as a reduction of what I saw as the beauty of Python. Perhaps switching to a statically typed language is preferable to bolting on types to a dynamic language.
That’s valid. I’m pretty rigorous about typing new code, but don’t make any heroic efforts to go back and retrofit old, well-tested code. `mypy --check-untyped-defs` gives a lot of bang for the buck for checking existing code without going all-in.
I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.
One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.
But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.
I've been seeing a lot of talk about htmx but I've been blissfully ignoring it as I've been reasonably successfully using Turbo and Hotwire. This move is a sign for me to take a deeper look into htmx as a potential replacement in the future.
Does anyone happen to have any good resources bookmarked for replacing Hotwire / Turbo with htmx? I'm also open to hearing about other similar tools in the area.
I think TypeScript is more useful for guiding the IDE than checking the types. And that might be enough value to adopt it.
It's just my feeling. But I don't feel like TS is preventing me to shoot my foot. The bugs that I write, even when the language doesn't support types, are rarely the kind that type checking would prevent.
"Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others."
> Fully recognize that TypeScript offers some people some advantages, but to my eyes, the benefits are evident in this PR. The code not only reads much better, it's also freed of the type wrangling and gymnastics needed to please the TS compiler.
This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for productivity. You get to drive at full speed towards the cliff.
Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
> Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
After years of writing Julia (dynamic) and C++ (static), I'm willing to die on that hill too.
But I've encountered more people who disagree with me than agree, so I'm not surprised by seeing a PR like this.
Doesn't scale to large projects and your dependencies. Requiring `map` to be type stable when calling dependencies is a maintenance nightmare in Julia.
This is a great analogy and succinctly summarizes my feelings on the matter. Just like you don't need tests for a quick prototype or for every last little bit of code, the same goes for static type checking, but past a certain point it's a must have.
I'll join you on that hill. I'd rather "fight" my IDE/the compiler than have runtime errors. Also writing code in a dynamic language is painful after you used a statically typed language in combination with a good IDE
Regardless of if you like TS or not, merging this changeset without addressing a single concern/comment in less than 2 hours shows that obviously DHH doesn't give a shit about contributors.
Not to mention adding 0 comments or written documentation in places where the types were literally the only documentation on what the arguments should have been. (For example string literal typed arguments ('on' | 'off'), places where only certain types of elements were expected, etc)
If I were a contributor to this, this would be my last day as one.
I don’t know what to say except “DHH gonna be DHH”. Decades of experience shows this sort of thing is what you buy into when you build on 37signals code (which isn’t necessarily bad).
Regarding this, it's a pity there's no officially maintained support for the language server protocol in TypeScript, and the last update from MS on the issue is from two years ago ("We've had personnel changes"): https://github.com/microsoft/TypeScript/issues/39459#issueco...
Meh, this debate is already long over. Every TypeScript alternative/competitor is dead. Most developers who are staunchly against TS types and compile steps for their JS code still probably end up relying on TypeScript via their editor's intellisense/language support even if they don't know it.
> it's also freed of the type wrangling and gymnastics needed to please the TS compiler.
If you're fighting typescript that much, then what's the point?
The point of using things like types is correctness that can be statically checked. Imagine writing java (or any static typed lang) code where you just pass around a base class( e.g. "Object") and explicitly cast up to what you want, there'd be no point in using that language.
> If you're fighting typescript that much, then what's the point?
Agreed - I find these "wrangling" situations to be uncommon, and roughly half of the time they happen because our code is bad and we need to change it. The other half - well, sure, it can be a pain in the ass, but there's no such thing as code so elegant that it never has some irritating high-effort corner cases. I'll take deterministic type wrangling over raw untyped JS.
Every time I’ve had to “wrangle typescript” it’s been converting old JS files where someone has done something that neither me nor typescript can work out what is going on.
Except that most code actually isn't passing around random unnamed objects of unknown type or contents. Their meaning and type are implied clearly enough in many if not most cases by their name and usage.
Hence, the downside is doing a lot of work to describe things we already know whilst making code less readable (or at least longer).
I'm still largely in favor of Typescript, I'm just suggesting to not misrepresent the situation of not having Typescript.
Do you have multiple people collaborating with you? If I’m writing code that only I need to understand then yes, typescript may be overkill (though I prefer types even then), but working on any meaningful codebase without types is… challenging. Types aren’t that hard are they?
I have, yes. From a team perspective, there's zero technical difference between TypeScript types and a combination of default args and type checker functions. The same ends are achieved, but in a far less kludgy way that's overt. In the event a type checker is missing, it can be added/documented quickly with zero time wasted on trying to answer "what's the TypeScript way to do this?"
Types aren't the difficult part, it's TypeScript that's difficult. The documentation is a nightmare and in my experience I saw "any" types being used far too often (which literally defeats the purpose of using TypeScript).
>there's zero technical difference between TypeScript types and a combination of default args and type checker functions
I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?
They are, but in practice there's little difference in the ends because you're getting the same feedback (did I pass the right type, yes or no). Like calling someone on a cell phone vs. a land line.
If the type of data you're passing around is erratic beyond development (where, just like TypeScript, a function-based approach illuminates incorrect data being passed around), you're writing bad code and TypeScript is nothing more than a crutch.
I expect most hardline TypeScript people to disagree, but type errors are the least of my concerns thanks to the above approach. It's not just an opinion; it's based on experience/evidence [1].
I'm going to be a bit of a naysayer here and comment that while I fully appreciate and endorse TypeScript... there are certainly situations where Javascript would be preferred. EG: Deno also dropped TypeScript internally.
What they've done seems a bit rough around the edges and a types file of some sort for external facing customers is a critical follow-up PR, but I would not blindly trash these guys for switching to Javascript. I suspect they did it so quickly because it would have sat in committee for eternity otherwise.
I probably wouldn't write anything in pure JavaScript today when TypeScript is such an enormous boon... but I'm also not working in the space that this project is working in.
Hi all, I work on the TypeScript team. There's already a lot of feedback on the issue itself from users urging the authors not to make this decision, so I will hold back from adding to the noise on that issue. Every team is entitled to make the decisions that they feel are best for them, and I don't think it'd be productive to change anyone's mind in this case.
Instead I'll just mention that I always welcome thoughts on some of the challenges teams encounter when writing in TypeScript. It helps make the language better. If there's anything you often hit, you can comment here, create an issue on the issue tracker, or reach out to me at Daniel <dot> Mylastname <at> microsoft <dot-com>
Typescript has been revolutionary and made me love doing frontend work. It’s solved so many issues with reliability that I’d never suggest using an untyped framework like rails for a new project.
In our team it's causing a lot of confusion an inconsistency that types and interfaces overlap 90% in functionality, but have different syntaxes.
You can find many articles trying to explain which is best under which circumstances, but there are no correct answers.
I would wish for TS to deprecate one of the syntaxes (probably interfaces because they read as statements rather than expressions), and instead extend the other with the 10% functionality that would be lost.
For instance a type could be declared as open, to make it possible to reopen and extend it.
I even saw a Youtube video recently making a strong case that types are almost always the better option unless you run into a few niche use cases like needing interface merging.
Even as someone who is very proficient in TypeScript, and an advocate, it's a huge PITA having to constantly ctrl+click through large type hierarchies trying to build a mental model of fully resolved types.
TS feels like a fever dream. It's as if a concentrated group of people were so convinced of a solution, that despite all available "parol" or academic evidence, they foisted it upon the ecosystem doing untold amounts of damage for years to come.
And if you don't use it, well it's because you simply don't understand types and your code base will be riddled with bugs! (lol)
The best, most testable, falsifiable argument I have heard for typescript is that helps with certain IDE's; but personally I haven't noticed a difference. In fact, TS causes me to go into dead ends with VS Code trying to hunt for the actual implementation of something in sizable code bases to the point where I'll just look at even the minified code to figure out what's actually going on.
Because at the end of the day, TS isn't an actual type system. It's a bunch of macros that sit on type of a jazz'd up linter (yes I am being editorial here). I have been coding for a long time, and personally I have never jumped into a TS code base and gone "oh thank god they decided to abstract this correctly!" These days it's met with a sigh and knowing a simple task is going to take me 10x as long to do than it would with any other tech stack.
Don't even get me started on the bugs TS itself has caused over the years.
People have often and loudly pointed out how awful web development can be (and was) over the last 20+ years but honestly, TS has been pretty pointlessly painful. The pain in yesteryear's was due to competing interests and the fact that many aspects of web development were just brand new.
It's a mistake we just need to fess up to as an industry.
Counter arguments to what exactly? What arguments are being proposed? Where? By Whom? Can you quote them?
The burden of proof is not on anyone else to prove that TS is making a beneficial difference. The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.
This is just a repeat of the "Surely OOP will solve all these different class of problems, trust me!" conversation the industry already had and I thought we had matured past.
Making a drive by dismissal comment that has quite grandful stands isn't really driving the conversation anywhere. You could have at least disagreed in detail.
Well that’s certainly a hot take. I’d say TypeScript is the best thing to happen to JS, but that’s just my opinion. It’s not perfect, but it makes working on a large codebase tolerable. To each their own.
The arrival of TypeScript has coincided with a massive, massive increase in code quality and engineering robustness within the Javascript library ecosystem.
Sure Javascript itself has increased in popularity and brought a new breed of software engineer into the mix, but it's probably not a coincidence that the people leading a lot of these modern and now ubiquitous library/framework efforts are drawn to TypeScript; people who probably wouldn't have touched Javascript with a 10 foot pole otherwise.
Many people in the PR mentioned the complexity that Typescript brings. But wasn't it an over simplification from the language from the beginning?
I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..
In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors
The analogy I like to use for this is JS is like your first car and TS is like your car ten or twenty years later. When you’re driving in your current car, fiddling with the settings, you might look back with nostalgia at your first car and how simple and fun it was and how free you felt. Then if you ever get an opportunity to drive that car or one like it again, you quickly realise that no, actually it was pretty shit, broke down more, didn’t warn you about things that needed checking or refilling and that it’s missing all the luxury comforts you’ve become accustomed to. Once you’re back in that banger you very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.
> very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.
I fixed our 2006 Saturn Ion lots of times and it runs very well. It's generally simple and the parts are relatively cheap.
I've been tempted to get a fancy Land Rover, Audi, BMW, Telsa. I want shiny things like lane positioning assistance, blind spot monitoring and even self-driving etc.
But they always seems to need a lot of maintenance, need fancy high grade fuels and when they break down, it's rarely fixable for the average person.
You do make some valid points but I wouldn't want to work on any kind of large scale codebase that used Javascript over Typescript. Even working in a Typescript codebase of hundreds of thousands of lines I've seen poorly named functions returning data types you wouldn't expect and poorly named variables. I can only imagine the hell if it was a pure javascript codebase and the actual types these things were returning weren't defined somewhere and you had to rely on the debugger for everything or delve through the codebase. Now your IDE catches it before you even run the code. I suppose if we were trying to extend this to the analogy, it's more productive and economical for any company with a substantial fleet of vehicles to run the newer models than it is trying to keep the old ones on the road.
I often find that types in typescript are bolted on and the whole thing gets pretty messy. I like typed languages like Java where the type system is more built into the language.
Yes that's valid TypeScript, but is it good TypeScript? One should take a ternary nested that deep as a sign that refactoring is needed. You can write terrible code in any language, that doesn't make the language problematic.
Agreed that terrible code can show up in any language. For some reason, I notice it more with TS. Here's a random example too (not saying this is terrible, just confusing to me):
>Yes that's valid TypeScript, but is it good TypeScript?
If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
* Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces.
* ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility.
* Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
I don't actually know off the top of my head how to refactor it - I've never had to write or deal with a type that complicated. It might actually be the best way of writing that specific type, in which case yes that kind of sucks, but I feel like it's probably not based on how hard it is to parse.
That’s not good TypeScript but I’ll note that I’ve seen a ton of nasty Java where everything is declared as taking “object”, and they’re abusing ternary operators just as badly (I remember this dude who had an allergy to if statements even if his ternararies wrapped into more lines), and lots of errors caught & ignored to avoid the “inconvenience” of handling them.
This doesn’t mean that Java is a bad language, only that it can be used badly.
If seen a lot of code like this and I f.hate it. Devs try and be too clever. With great power... etc
Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy.
However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison.
Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness.
The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler.
I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).
TypeScript excels at informing IDE's and developers. Typing improves my ability to understand APIs both as a library user and contributor. So I see the benefit exceeds the issues of TypeScript.
A better approach would be a more gradual. Perhaps keep the .ts files (or at least develop .d.ts files) for the public API and main components.
No one could accuse DHH of being an amateur, and it's true that static typing is an obstacle if it's not a vehicle.
It took me years to "get on the other side" of typing, and wield it productively instead of battling against it. I have heard several developers express the same way about testing, ie when one learns to test first, one no longer resents the tests (or whoever mandates them). Resentment and frustration give way gratitude and elation--but admittedly, it takes more than "five minutes".
Static typing has a similar feel for me (although I am no expert): type-driven design often unfolds fantastically, easily, and beautifully. It has certainly replaced a few categories of unit test. Inability to appreciate static typing as a tool is, for most developers, a "skill issue." It certainly took me more than five years to come around to static typing, although as I explore it deeper (perhaps after another five years), I'll undoubtedly discover areas in which the emperor's showing a little skin.
Again, however, no one could accuse DHH of a skill issue. Perhaps he is looking out for the little guy? Perhaps he's simply invested in an alternate idiom. Perhaps he really is a whole five years of static typing grief ahead of us. I think that's certifiable.
He does say that he started at 'hate it' and never left so it may just be a preference thing. I think it's fair that a maintainer makes choices that make the project easier to maintain (for them), but I wonder if it's really just that they picked up TS unwillingly and simply never really came around to it.
126 comments
[ 1.7 ms ] story [ 231 ms ] threadSo as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case.
I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. They don’t. They just become implicit. It takes something a computer is really good at, and shoves it into your brain. And as many point out: the types are, more than anything, documentation.
But beyond any of that (and I feel this is the most important lesson): when there’s like a 100:1 ratio in favour of something, you’re probably wrong. Not always. But probably. And it’s your ball. You can take it and go home if you want. People can fork. But sometimes you need to, at best, say, “I simply do not understand you people, but you’re the overwhelming majority, so whether I like it or not, I need to leave things as-is.”
Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.
I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
That doesn't seem to be what this is about, though.
I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.
TS isn't an extra layer of complexity.
Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity.
Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity.
Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity.
Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity.
Typescript makes you pay up front to remove a LOT of complexity down the line.
TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't.
I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types.
OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever.
Just, like, no.
Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
> [V]ery few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it.
Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement.
(I like neither JS nor TS, so eh.)
Sounds like a project I'd stay away from.
With comments like "Also, TypeScript hurts to write. Good riddance."
What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transpiler) step on the front-end simply too much to ask?
I say this as a lead on an enterprise Angular project who used to loathe front-end development (for 20+ years). TypeScript has brought back some sanity.
This was often the case ~10 years ago when TS was first introduced. A lot of JS developers at the time liked that static type checking was impossible.
I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.
It's incredibly helpful to move fast on large projects.
It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.
I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.
Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.
That's just one simple example.
Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.
I see much hate on DHH for doing this, but I sincerely support him on many levels. And I am glad someone was bold enough to do this so publicly. Go team JS!
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
I think this is the honest answer!
So is it worth it in the end? Probably, and I'd use them in personal projects and run mypy as well, but I feel that the Python community could be taking it too far. Type annotations were supposed to be gradual opt in (and they still can be), but nowadays it doesn't feel that way, and while I appreciate the benefits brought by using them, I can't help lamenting what I see as a reduction of what I saw as the beauty of Python. Perhaps switching to a statically typed language is preferable to bolting on types to a dynamic language.
I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.
One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.
But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.
Does anyone happen to have any good resources bookmarked for replacing Hotwire / Turbo with htmx? I'm also open to hearing about other similar tools in the area.
It's just my feeling. But I don't feel like TS is preventing me to shoot my foot. The bugs that I write, even when the language doesn't support types, are rarely the kind that type checking would prevent.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
Hashtag irony.
This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for productivity. You get to drive at full speed towards the cliff.
Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
Devil's Advocate: I actually can't, absolutely **** take.
After years of writing Julia (dynamic) and C++ (static), I'm willing to die on that hill too. But I've encountered more people who disagree with me than agree, so I'm not surprised by seeing a PR like this.
Not to mention adding 0 comments or written documentation in places where the types were literally the only documentation on what the arguments should have been. (For example string literal typed arguments ('on' | 'off'), places where only certain types of elements were expected, etc)
If I were a contributor to this, this would be my last day as one.
But TypeScript the language is great – I spent 3+ years each working with C++ and Java, and TS's type system is much more expressive and useful.
I wish people would distinguish whether or not they object to the tooling, or the language.
Regarding this, it's a pity there's no officially maintained support for the language server protocol in TypeScript, and the last update from MS on the issue is from two years ago ("We've had personnel changes"): https://github.com/microsoft/TypeScript/issues/39459#issueco...
If you're fighting typescript that much, then what's the point?
The point of using things like types is correctness that can be statically checked. Imagine writing java (or any static typed lang) code where you just pass around a base class( e.g. "Object") and explicitly cast up to what you want, there'd be no point in using that language.
(And ran.)
Agreed - I find these "wrangling" situations to be uncommon, and roughly half of the time they happen because our code is bad and we need to change it. The other half - well, sure, it can be a pain in the ass, but there's no such thing as code so elegant that it never has some irritating high-effort corner cases. I'll take deterministic type wrangling over raw untyped JS.
Hence, the downside is doing a lot of work to describe things we already know whilst making code less readable (or at least longer).
I'm still largely in favor of Typescript, I'm just suggesting to not misrepresent the situation of not having Typescript.
[1] https://twitter.com/cheatcodetuts/status/1692256529628512667
Types aren't the difficult part, it's TypeScript that's difficult. The documentation is a nightmare and in my experience I saw "any" types being used far too often (which literally defeats the purpose of using TypeScript).
I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?
If the type of data you're passing around is erratic beyond development (where, just like TypeScript, a function-based approach illuminates incorrect data being passed around), you're writing bad code and TypeScript is nothing more than a crutch.
I expect most hardline TypeScript people to disagree, but type errors are the least of my concerns thanks to the above approach. It's not just an opinion; it's based on experience/evidence [1].
[1] https://github.com/cheatcode/joystick
Tells this haskeller / TSer everything I need to know.
What they've done seems a bit rough around the edges and a types file of some sort for external facing customers is a critical follow-up PR, but I would not blindly trash these guys for switching to Javascript. I suspect they did it so quickly because it would have sat in committee for eternity otherwise.
I probably wouldn't write anything in pure JavaScript today when TypeScript is such an enormous boon... but I'm also not working in the space that this project is working in.
Instead I'll just mention that I always welcome thoughts on some of the challenges teams encounter when writing in TypeScript. It helps make the language better. If there's anything you often hit, you can comment here, create an issue on the issue tracker, or reach out to me at Daniel <dot> Mylastname <at> microsoft <dot-com>
You can find many articles trying to explain which is best under which circumstances, but there are no correct answers.
I would wish for TS to deprecate one of the syntaxes (probably interfaces because they read as statements rather than expressions), and instead extend the other with the 10% functionality that would be lost.
For instance a type could be declared as open, to make it possible to reopen and extend it.
Even as someone who is very proficient in TypeScript, and an advocate, it's a huge PITA having to constantly ctrl+click through large type hierarchies trying to build a mental model of fully resolved types.
And if you don't use it, well it's because you simply don't understand types and your code base will be riddled with bugs! (lol)
The best, most testable, falsifiable argument I have heard for typescript is that helps with certain IDE's; but personally I haven't noticed a difference. In fact, TS causes me to go into dead ends with VS Code trying to hunt for the actual implementation of something in sizable code bases to the point where I'll just look at even the minified code to figure out what's actually going on.
Because at the end of the day, TS isn't an actual type system. It's a bunch of macros that sit on type of a jazz'd up linter (yes I am being editorial here). I have been coding for a long time, and personally I have never jumped into a TS code base and gone "oh thank god they decided to abstract this correctly!" These days it's met with a sigh and knowing a simple task is going to take me 10x as long to do than it would with any other tech stack.
Don't even get me started on the bugs TS itself has caused over the years.
People have often and loudly pointed out how awful web development can be (and was) over the last 20+ years but honestly, TS has been pretty pointlessly painful. The pain in yesteryear's was due to competing interests and the fact that many aspects of web development were just brand new.
It's a mistake we just need to fess up to as an industry.
> 10x dev time
> bugs
> pointlessly painful
> it’s a mistake
Your comment seems very emotional and doesn’t add any concrete counterarguments.
The burden of proof is not on anyone else to prove that TS is making a beneficial difference. The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.
This is just a repeat of the "Surely OOP will solve all these different class of problems, trust me!" conversation the industry already had and I thought we had matured past.
Making a drive by dismissal comment that has quite grandful stands isn't really driving the conversation anywhere. You could have at least disagreed in detail.
I highly doubt that this is the case. I also doubt that you can back this up.
I personally only had one bug that was caused by TS itself (https://github.com/microsoft/TypeScript/issues/40726) so I'm curious to hear about the issues you encountered.
The arrival of TypeScript has coincided with a massive, massive increase in code quality and engineering robustness within the Javascript library ecosystem.
Sure Javascript itself has increased in popularity and brought a new breed of software engineer into the mix, but it's probably not a coincidence that the people leading a lot of these modern and now ubiquitous library/framework efforts are drawn to TypeScript; people who probably wouldn't have touched Javascript with a 10 foot pole otherwise.
I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..
In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors
I fixed our 2006 Saturn Ion lots of times and it runs very well. It's generally simple and the parts are relatively cheap.
I've been tempted to get a fancy Land Rover, Audi, BMW, Telsa. I want shiny things like lane positioning assistance, blind spot monitoring and even self-driving etc.
But they always seems to need a lot of maintenance, need fancy high grade fuels and when they break down, it's rarely fixable for the average person.
Typescript errors are also very annoying to read.
This is TS code - and I think it's crazy.
type DeepPartial<T> = { [P in keyof T]?: T[P] extends (infer U)[] ? DeepPartial<U>[] : T[P] extends ReadonlyArray<infer U> ? ReadonlyArray<DeepPartial<U>> : T[P] extends object ? DeepPartial<T[P]> : T[P]; };
https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
* Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces.
* ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility.
* Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
This doesn’t mean that Java is a bad language, only that it can be used badly.
Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy.
However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison.
Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness.
The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler.
I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).
> things that are hard become `any`.
It's a hard problem to solve.
TypeScript excels at informing IDE's and developers. Typing improves my ability to understand APIs both as a library user and contributor. So I see the benefit exceeds the issues of TypeScript.
A better approach would be a more gradual. Perhaps keep the .ts files (or at least develop .d.ts files) for the public API and main components.
It took me years to "get on the other side" of typing, and wield it productively instead of battling against it. I have heard several developers express the same way about testing, ie when one learns to test first, one no longer resents the tests (or whoever mandates them). Resentment and frustration give way gratitude and elation--but admittedly, it takes more than "five minutes".
Static typing has a similar feel for me (although I am no expert): type-driven design often unfolds fantastically, easily, and beautifully. It has certainly replaced a few categories of unit test. Inability to appreciate static typing as a tool is, for most developers, a "skill issue." It certainly took me more than five years to come around to static typing, although as I explore it deeper (perhaps after another five years), I'll undoubtedly discover areas in which the emperor's showing a little skin.
Again, however, no one could accuse DHH of a skill issue. Perhaps he is looking out for the little guy? Perhaps he's simply invested in an alternate idiom. Perhaps he really is a whole five years of static typing grief ahead of us. I think that's certifiable.