Remove TypeScript
github.com
github.com
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.”
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.)
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.
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.
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.
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.
Tells this haskeller / TSer everything I need to know.
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.
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 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.
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...
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.
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).
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
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.
Yes, I get it, for most usecases, most people today prefer TS, but in the end, the team weighed their options and they made a decision they are happy with.
Open source, as strange as it sounds, doesn't mean that the maintainers need to ask for the approval of everybody who read some tweets and join the pile on.
For those who disagree with their decision and are actually affected, vote with your feet, and don't rely on anything hey or dhh related. If you don't have a choice but to keep using them and you hate this change, I feel your pain.
I don't know enough about turbo to know if it's a bad decision or not, but I don't mind people going against the grain. If people like that wouldn't exist, I'd still need to work with Scrum (in the end, how dare you challenge the collective wisdom that scrum is the greatest thing since slice bread).
They may succeed or fail, but at least they fail in their own terms and enjoy their work on their product with the language they like.
It should seem strange - that's not what's happening.
People are upset about the decision to drop a layer of tooling, yes. People are also upset about a rush job of ripping out that layer, losing information and deleting documentation. People are also upset about a total disregard of feedback and extremely quick decision merging. These are all very normal things to be upset about.
I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes.
Presumptuous is a word that comes to mind.
The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
But, they're responding to the behavior and the intentions as much as the decision itself. That's my point. It's disingenuous and pretentious to insult the lot for simply reacting to the decision to remove a tool because that's not what they're reacting to, not entirely.
> The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
Fair, but a totally separate point.
Just like in this thread -- lots of people whinging about how something they don't contribute to is built, by the team that builds it. Which is both obnoxious and arrogant.
Glance at the contributors page and you'll see who has earned the right to have an opinion on how turbo is built.
Pretty funny, considering one of Eich's regrets about JavaScript is allowing things like `1 == "1"`
Typescript is totalitarian. It consumes you whole. It makes no sense to partially adapt it as its supposed benefits will then never materialize. The deeper you're in, the more motivated you'll get to go even deeper.
This is entirely opposite from writing unit tests. Everybody hates to do that, you'll never have coverage to match real world complexity and it easily breaks under time pressure. The more you try to get it to work, the more you hate it and just want to give up on it. Typescript is different, it has a point of no return.
That being said, we should check our passion. Tech discussions have a high degree of confirmation bias coming from a small very vocal minority. This same minority that would advance React, Tailwind, and similar choices as the one and only industry standard.
It's not representative of the wider developer community, most of which are silent. Nor is it representative of every use case one can build on the web, every project size, team size, etc.
As for DHH, it's an unsurprising move. He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess. I think the general point has merit, as to whether the specific point of Typescript fits into that narrative, is debatable. Personally, I think project size/complexity and team size/skill levels are big factors.
I strongly disagree. Web/front-end development was always a hot mess. It's just that when we were using Perl to write CGI.pm pages, we didn't have good tooling to tell us all the terrible things we were doing.
Modern tooling just shines a light on our mistakes. It didn't make them for us. Those simpler times only existed in the sense that we were blissfully ignorant of our sins.
What I mean to say is that web development was more accessible during simpler times. People from all walks of life would develop websites, flash stuff, and even dynamic sites, i.e. LAMP. They could do that because it was simple enough to learn.
Front-end development as we typically do it today has turned into a hardcore engineering discipline of staggering complexity.
It is in fact so engineering-heavy that even within the world of professional front-end development it has caused a split where there's a "front of the front-end" (CSS, UX, accessibility) and a "back of the front-end" (the engineering part).
You may be able to justify every single tool, command line, pattern or best practice and it's not my point to talk you out of it. My point is to zoom out and consider this larger pattern.
(Bystanders, don't "correct" me with "technically you still can...", etc. I know. It's all just text, right? But the parent poster is absolutely right about the general state of things.)
Whilst hobbyists can still use whatever they want, including simple options, I in particular empathize with those new to the field or looking to turn a hobby into a job.
You need to know React/Typescript/CLIs/Docker/Git/Unit testing/IDEs/CSS/5 million other things. Or there's simply not going to be a job for you at all.
So "just don't use it" doesn't apply.
On the upside, once you do master the unwarranted complexity, pay is great. Fiddling around with toys and a Frankenstein tech stack whilst continuing to produce outcomes with worse UX than 15 years ago is somehow richly rewarded. It paid for my quality of life so let's add some more "absolutely essential" tools.
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've also had the pleasure of working on a JS-only project, and I would've killed to have typescript there. It was anyone's guess what any method call would be doing, what arguments were being passed around etc. I can't imagine working in a large JS codebase, especially with other contributors, without types to back you up.
[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].
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”.
> 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.
https://agileforall.com/history-of-tdd-as-told-in-quotes/
Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”
I was doing Java back (during Kent Beck days of XP etc) and although I had heard of JUnit (and even heard Kent Beck preach about this at a conference) and it sounded cool, no team or company I knew was using it seriously.
It's only when Rails came around where if (I believe if memory serves me right) the default controller/views generators created tests automatically. Ruby being a dynamic language and no compile step, you couldn't prove correctness before running it, meant you were skating on thin ice if you didn't write tests.
That's pretty much a given.
I know someone people that worked at Xerox (when Steve Jobs visited) and they pretty much invented everything. lol.
I've been told stories that pretty much technology after Xerox is a derivative from that time. Sure, I take that with a pinch of salt, but I half/mostly believe it.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
Hashtag irony.