10 ms·
Remove TypeScript
- aranw 3y agoTalk about move fast and break things!
- Waterluvian 3y agoAfter 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.”
- incrudible 3y agoJavascript 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.
- Waterluvian 3y agoThat’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.
- digging 3y 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?
- incrudible 3y agoYou are using Typescript to prove that they're correct. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
- skybrian 3y agoOne 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.
- Waterluvian 3y agoHmmm 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.
- com2kid 3y 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 3y agoI 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.
- acdha 3y agoI 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.
- Jcampuzano2 3y agoMerging 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 3y agoWhat 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.
- petesergeant 3y agoI 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.
- arghwhat 3y agoTo 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_386 3y agoRemove 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 3y 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.
- brailsafe 3y agoI 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_386 3y 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.
- shepmaster 3y agoI'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 3y agoI 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 3y agoAssociated blog post: https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01 https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
- tasn 3y 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...
- deleted 3y ago[deleted]
- killthebuddha 3y agoDisclaimer: I agree with you. Devil's Advocate: I actually can't, absolutely **** take.
- celrod 3y 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.
- 3y ago
- Jcampuzano2 3y agoRegardless 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 3y agoI 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).
- TehShrike 3y agoI'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 3y agoWhat do you use for type checking in dev - tsserver? https://github.com/microsoft/TypeScript/wiki/Standalone-Server-(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#issuecomment-929532650 https://github.com/microsoft/TypeScript/issues/39459#issueco...
- TehShrike 3y agoYeah I use LSP-typescript in Sublime Text, which uses typescript-language-server, which is backed by tsserver.
- monkpit 3y agoWhat’s wrong with tsc on local?
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- paxys 3y agoMeh, 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.
- mplewis 3y agoAnother 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 3y agoIt's spiteful comments like this that actually convince me he's making great bold decisions
- preommr 3y 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 3y agoI've worked in that place. (And ran.)
- digging 3y 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.
- Gigachad 3y agoEvery 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.
- dahwolf 3y agoExcept 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 3y agoThey sure do like to be contrarian.
- rglover 3y agoThis 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 https://twitter.com/cheatcodetuts/status/1692256529628512667
- ink 3y agoDo 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?
- rglover 3y agoI 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).
- ink 3y agoFair enough if you have another way that works!
- dmux 3y ago>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?
- sibeliuss 3y ago
- maxcan 3y 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.
- arecurrence 3y agoI'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 3y agoHi 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 3y agoI’d just like to say thank you for your team’s hard work on TypeScript. I can’t imagine writing JavaScript without TypeScript.
- Gigachad 3y agoTypescript 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 3y agoIn 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.
- Rapzid 3y agoI 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.
- whoknowsidont 3y agoTS 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.
- Rapzid 3y agoHere 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.
- monkpit 3y 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.
- Julien_r2 3y agoMany 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
- deleted 3y ago[deleted]
- rcarr 3y agoThe 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.
- vlod 3y 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.
- rcarr 3y agoYou 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.
- gardenhedge 3y agoI 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]; };
- digging 3y agoYes 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.
- gardenhedge 3y agoAgreed 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/utils/types/Strict.ts https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
- whoknowsidont 3y 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?
- wk_end 3y agoSome combination of: * 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.
- logN_2 3y agoThe 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 3y agoNo 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.
- gsuuon 3y agoHe 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 3y agoThe 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.
- digging 3y 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.
- whoknowsidont 3y 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).
- digging 3y ago
- dahwolf 3y agoTypescript 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.
- kstrauser 3y 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.
- dahwolf 3y agoI 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.
- gsuuon 3y agoIt'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 3y 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 3y agoIf "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 https://twitter.com/BrendanEich/status/1440088359473324036.
- dmux 3y agoIt 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.
- vlod 3y agoI expect they have a very large unit/integration test suite. Rails was the first (or very early pioneers) of doing TDD.
- _phred 3y agoA very cursory internet search shows that your history is entirely wrong: https://agileforall.com/history-of-tdd-as-told-in-quotes/ 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.”
- vlod 3y agoSure, everything could probably be tracked back to the good golden years, but who was really doing TDD before Rails? 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.
- vlod 3y ago> “[stood] on the shoulders of giants.” 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.
- sensanaty 3y agoI'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.