Remove TypeScript

https://github.com/hotwired/turbo/pull/971

by corentin88 • 3 years ago

139 121 3 years ago

aranw2• 3 years ago

Talk about move fast and break things!

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

incrudible2• 3 years ago

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.

Waterluvian3• 3 years ago

That’s true. For Python I add them as needed. It’s not all or nothing. You can change tsconfig to be fine with implicit any.

digging6• 3 years ago

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?

skybrian• 3 years ago

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.

Waterluvian3• 3 years ago

Hmmm you got me thinking. I wonder if there’s a sensible story for ts to “compile” to JS with jsdoc annotations.

I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.

com2kid2• 3 years ago

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.

IggleSniggle• 3 years ago

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.

acdha4• 3 years ago

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.

Jcampuzano22• 3 years ago

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.

n2d4• 3 years ago

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.

arghwhat• 3 years ago

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.

(I like neither JS nor TS, so eh.)

EMM_3862• 3 years ago

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.

Veuxdo• 3 years ago

Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing?

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.

brailsafe2• 3 years ago

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.

EMM_3862• 3 years ago

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.

That's just one simple example.

mplewis2• 3 years ago

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.

aranw2• 3 years ago

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

bestest• 3 years ago

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!

kstrauser4• 3 years ago

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.

sibeliuss2• 3 years ago

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!

happyraul• 3 years ago

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.

shepmaster• 3 years ago

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.

haolez• 3 years ago

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.

threatofrain• 3 years ago

Associated blog post:

https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

gnabgib• 3 years ago

Seems like a better submission URL too

davidrupp• 3 years ago

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

Hashtag irony.

tasn• 3 years ago

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

killthebuddha• 3 years ago

Disclaimer: I agree with you.

Devil's Advocate: I actually can't, absolutely **** take.

celrod2• 3 years ago

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.

xgdgsc• 3 years ago

Just tried the latest Cthulhu.jl and vscode integration. Dynamic by default and can infer and show types might be perfect.

Etheryte• 3 years ago

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.

bafe• 3 years ago

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

Jcampuzano22• 3 years ago

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.

wrs• 3 years ago

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

TehShrike2• 3 years ago

I've found the TypeScript tooling story to be a bit clunky (protip: use tsc --noEmit for type checking in CI, but don't use tsc for anything else).

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.

tuukkah• 3 years ago

What do you use for type checking in dev - tsserver? https://github.com/microsoft/TypeScript/wiki/Standalone-Serv...

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

TehShrike2• 3 years ago

Yeah I use LSP-typescript in Sublime Text, which uses typescript-language-server, which is backed by tsserver.

monkpit2• 3 years ago

What’s wrong with tsc on local?

paxys• 3 years ago

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.

preommr• 3 years ago

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.

sverhagen• 3 years ago

I've worked in that place.

(And ran.)

digging6• 3 years ago

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.

Gigachad2• 3 years ago

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.

dahwolf4• 3 years ago

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.

andrewstuart• 3 years ago

They sure do like to be contrarian.

rglover4• 3 years ago

This is the correct move. A hot take I recently posted that has caused me zero issues over the past few years: [1].

[1] https://twitter.com/cheatcodetuts/status/1692256529628512667

ink4• 3 years ago

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?

rglover4• 3 years ago

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

maxcan• 3 years ago

The fact is that I actually rather like JavaScript. I'd go so far as to say it's my second favorite language after Ruby.

Tells this haskeller / TSer everything I need to know.

mplewis2• 3 years ago

Another bad decision from the desk of DHH. I'm glad he's actively ruining his projects – it's time for people to move onto better software.

jack_riminton• 3 years ago

It's spiteful comments like this that actually convince me he's making great bold decisions

arecurrence• 3 years ago

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.

DanRosenwasser• 3 years ago

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>

alexlur• 3 years ago

I’d just like to say thank you for your team’s hard work on TypeScript. I can’t imagine writing JavaScript without TypeScript.

Gigachad2• 3 years ago

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.

jeppester• 3 years ago

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.

Rapzid4• 3 years ago

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.

Rapzid4• 3 years ago

Y'all have been ignoring the largest DX issue in TypeScript for years: https://stackoverflow.com/questions/57683303/how-can-i-see-t...

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.

whoknowsidont4• 3 years ago

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.

monkpit2• 3 years ago

untold damage
10x dev time
bugs
pointlessly painful
it’s a mistake

Your comment seems very emotional and doesn’t add any concrete counterarguments.

whoknowsidont4• 3 years ago

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.

ink4• 3 years ago

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.

dezsiszabi• 3 years ago

I know you said don't get me started on the bugs TS caused, but I would like to hear about them if you don't mind.

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.

Rapzid4• 3 years ago

Here is my take..

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.

Julien_r2• 3 years ago

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

rcarr2• 3 years ago

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.

vlod5• 3 years ago

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.

rcarr2• 3 years ago

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.

gardenhedge2• 3 years ago

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.

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]; };

digging6• 3 years ago

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.

gardenhedge2• 3 years ago

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

https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...

whoknowsidont4• 3 years ago

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?

gsuuon3• 3 years ago

But we can hide those utility types in a deep dark util.ts hole and never look at them ever again

acdha4• 3 years ago

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.

vlod5• 3 years ago

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

logN_2• 3 years ago

The key thing from David's blog post:

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.

gavmor• 3 years ago

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.

gsuuon3• 3 years ago

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.

serial_dev• 3 years ago

The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange.

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.

digging6• 3 years ago

The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange.

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.

whoknowsidont4• 3 years ago

It should seem strange - that's not what's happening.

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

x0x0• 3 years ago

The majority of people complaining are not contributors to the project at all, or for the one or two I saw that are, had a handful of commits.

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.

ink4• 3 years ago

I think dropping Typescript the way they did was silly, but you are absolutely correct that they should be able to do so, even if it’s unpopular.

dahwolf4• 3 years ago

Typescript is divisive. People are passionate in loving it or hating it, not to forget a silent majority that never even tried it.

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.

kstrauser4• 3 years ago

He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess.

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.

dahwolf4• 3 years ago

I was looking at the bigger picture, and didn't clarify that point enough.

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.

gsuuon3• 3 years ago

It's easy to hate typescript if you're trying to write it as javascript with types bolted on. All you'll see is restrictions and arcane complexity which exists solely to assuage the compiler. If you instead write types first and go from there, the value becomes evident really fast - and you avoid writing untypeable code which likely would've grown into a difficult to reason about api.

favorited• 3 years ago

letting the rest of us enjoy JavaScript in the glorious spirit it was originally designed

Pretty funny, considering one of Eich's regrets about JavaScript is allowing things like `1 == "1"`

BrendanEich• 3 years ago

If "originally designed" refers to the ten-days-in-May Mocha then == on unlike type operands evaluated to false. I've told why this changed later many times, e.g., https://twitter.com/BrendanEich/status/1440088359473324036.

dmux2• 3 years ago

It would be interesting to track the bug rate after this commit and compare it to the bug rate in the Typescript version of the code base.

vlod5• 3 years ago

I expect they have a very large unit/integration test suite. Rails was the first (or very early pioneers) of doing TDD.

_phred• 3 years ago

A very cursory internet search shows that your history is entirely wrong:

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

sensanaty• 3 years ago

I'm a Rubyist at heart like DHH so I get not liking types, but after being involved in a pretty large Rust codebase where everything was typed and having my editor be able to know exactly what I'm trying to do in 99% of cases, I find it hard to go back to Ruby, especially if we're talking about a team setting where you're working with other devs. If I'm doing something solo I still prefer Ruby since I can just write the code and forget about it.

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.

Remove TypeScript

Related Stories