111–120 of 127 posts
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.
Earlier quoted context omitted.
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!
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 sh…
> 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. B…
Earlier quoted context omitted.
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!
I could copy and paste JS code into a REPL/browser console to find bugs/REPL-basee development, but that won't work for Typescript. Debuggers take some more time to set up too. More complex than other typed OOP languages like C# or Java which don't have these steps.
Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever.
Just, like, no.
Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
Earlier quoted context omitted.
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!
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…
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.
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…
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…
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…
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.
Earlier quoted context omitted.
> 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 feed…
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…
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.