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.
Remove TypeScript
91–100 of 127 posts
Re: Remove TypeScript
#92Remove 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 (transp…
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 ca…
> 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!
Re: Remove TypeScript
#93Earlier quoted context omitted.
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,…
>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?
Yes, you are correct. It is clear the OP doesn't understand the purpose of typescript.
Re: Remove TypeScript
#94Earlier quoted context omitted.
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,…
>there's zero technical difference between TypeScript types and a combination of default args and type checker functions I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?
They are, but in practice there's little difference in the ends because you're getting the same feedback (did I pass the right type, yes or no). Like calling someone on a cell phone vs. a land line.
If the type of data you're passing around is erratic beyond development (where, just like TypeScript, a function-based approach illuminates incorrect data being passed around), you're writing bad code and TypeScript is nothing more than a crutch.
I expect most hardline TypeScript people to disagree, but type errors are the least of my concerns thanks to the above approach. It's not just an opinion; it's based on experience/evidence [1].
Re: Remove TypeScript
#95Earlier quoted context omitted.
>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?
Yes, you are correct. It is clear the OP doesn't understand the purpose of typescript.
I understand perfectly, but in practice I don't think the benefits outweigh the costs.
Re: Remove TypeScript
#96Earlier quoted context omitted.
> 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…
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…
Also you don't write code that your processor executes and, at best, you use a layer of complexity known as assembly language. That's a shame!
Re: Remove TypeScript
#97Earlier quoted context omitted.
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, an…
> 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 rig…
Ya that's sort of what I meant by the rest of the comment, and I agree, in theory, but haven't personally encountered this because I've never come onto a project that's already had a well-established TS implementation. I'm always doing the implementation, and then lose my job before getting to the point where the benefits were realized, and it's quite a slow path to getting to a place where the full codebase of sufficient size is typed, simply because most huge cosebases have evolved over time and aren't completely JS or TS.
Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.
Re: Remove TypeScript
#98> 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 product…
> 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.
Just tried the latest Cthulhu.jl and vscode integration. Dynamic by default and can infer and show types might be perfect.
Re: Remove TypeScript
#99Remove 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 (transp…
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 ca…
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.
Re: Remove TypeScript
#100Earlier quoted context omitted.
Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision". If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
What I found ironic was this part from the reasoning post: > [V]ery few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others. Feels like projecting. I think very few programmers would feel this strongly about ty…
I mean it’s also simply not true. Most JS developers who have been doing JS for at least ten years have explicitly gone from not caring that much about types to being thankful for them.