421–430 of 469 posts
It goes both ways, a counter example which saved me from some frustration: plotly.js has a horribly bad online documentation, but their type def makes it super convenient to explore all the layout config stuff, when you're buildling a custom visualization.
In my experience, any npm library I try to use either already has community created types provided, is too simple to really need types/extra docs, or the docs will still be pre-es6 (pre important, pre async/await, etc.) so it's not like it was going to be convenient to learn anyways.
Hi there! I work on the TypeScript team and I respect your feedback. Of course I do think TypeScript is worth it, and I'll try to address some of the points you've raised with my thoughts. i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing bu…
Thanks for responding, and thanks for your work for the community! I sometimes place myself in the shoes of devs building TypeScript, especially when I am a little frustrated, and most of the time I realize that a lot of these issues are incredibly hard to solve. > i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference migh…
aozgaa has already answered this one - but yes! If you have a concrete suggestion, that's fair game and we can brainstorm on the issue to think of something. We might not come up with something general enough to implement, but it's often a good seed to plant.
> which in turn broke a type used from ProtobufJS.
I am curious to hear what sort of issue you ran into. Was this the Apollo fork (https://github.com/apollographql/protobuf.js), or the original?
> Is Typescript worth it? > I want to skip over the static typing benefits argument… Typescript, as the name implies, adds types to your script. If you don’t see the benefits of types then typescript may not be for you. > My issue is with the amount of extra work it places on developers… and doesn't deliver all that much value. If you think adding types doesn't add much value then typescript may not be for you. In my…
> If you think adding types doesn't add much value then typescript may not be for you. In my experience, types are defined once then provide a lifetime of value You have misunderstood the OP. The full paragraph is: >> I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing and if we could bless JavaScript with a built-in and robust typing syste…
I've used static langs like Java and GoLang and prefer them over TS. Heck I even like ruby-rails more. Since I'm fullstack (TS on FE/BE), it's hard to move 100% away from TS (becz a use React) and it irks me how everything has changed the last 10 years of so.
I am a seasoned developer and can code (in JS) extremely fast, clean and performant. With sufficient test coverage you can go a long way. Of course if you use TS and change something important, the compiler will tell you all the places you have to refactor. This is super useful.
However in my experience with a fair amount of TS codebases, there has been a tendency for devs to use as many clever TS features of possible (e.g. utility classes and generating crazy generic types from multiple types). I detest this style of programming, becz when you have to can't get something to work, it's a pain to try and understand the errors. This also extends to TS enabled libraries which can be challenging when you try and do something non-standard.
I burn time trying to understand the errors and getting TS out of my way, so I can get on with the task at hand. I find cases that if you look at the logic I've written, there's not a chance that something can be undefined and yet I have to wrap code in "if's" just to satisfy the compiler.
Even though I have a ton of experience, I deliberately code for that junior devs can understand/debug/work-with or the support engineer who just got woke up and trying to fix prod, which in my experience, isn't a common approach anymore. This is part of the problem IMHO.
Most devs I talk to are using TS as their first language and have mostly never experienced the joy (and lack of safety, I grant you) of dynamic/non-typed languages (e.g. ruby/lisp). Get a lisp-er to do TS and start hearing the flood of swear words. lol.
Of course, I understand the benefits of TS, but for me at least there's no joy in it and that's one of the reasons I got in this game in the first place.
Earlier quoted context omitted.
> TS saves me time every day. Hmm, not my experience. I do TS for years now and still today I'm spending more time on fighting/pleasing TS compared to the actual code. JS with all its node_modules dependencies is a complete nightmare to get the typing right. I regularly have to change good solid code to please TS, but at the same time TS often doesn't complain when the typing is obviously wrong. I once started with A…
I’m noticing a pattern in your arguments. You need to understand that I (and I suspect many others) don’t have the same experience as you. I don’t _fight/battle with_ the type system, I work with the type system - and I enjoy it. It saves me countless hours. I don’t actually use javascript without TypeScript anymore - it’s simply not worth _not_ using it - for me. You ask whether it’s worth using it - and you keep te…
I think Typescript isn't worth using, and I find this unfortunate. The Typescript team clearly has put years of work into this, and clearly has tried to shore up the deficiencies in Javascript. Are you writing a brand-new codebase that needs to work on multiple platforms, and not exclusively in a browser? Don't use Typescript, use a language with native WASM support. This includes avoiding solutions that involve Elec…
I mostly agree with this, and haven't been happy developing JS for some time. I don't enjoy having to deal with bundles, webpack, TypeScript, bloated dependency graphs. Luckily I can use Go for new projects, and even when picking it up at first I quickly found it more pleasurable to use than NodeJS. I don't JS on the backend if I can avoid it. On the frontend, I would still argue on balance SPA/bundling is the best o…
I find most companies don't do JS any more (TS experience is a requirement)
> Is Typescript worth it? > I want to skip over the static typing benefits argument… Typescript, as the name implies, adds types to your script. If you don’t see the benefits of types then typescript may not be for you. > My issue is with the amount of extra work it places on developers… and doesn't deliver all that much value. If you think adding types doesn't add much value then typescript may not be for you. In my…
> If you don’t see the benefits of types then typescript may not be for you. At this point in my 20+ year career working with mostly dynamic languages, my feeling is that if you don't see the benefits of types, then programming isn't for you.
Maybe it isn't "types" that is the problem, but the way types are implemented in TS. I never had these problems in Java as I do in TS.
I share your feelings. These times, whenever I'm setting up a new TS project, feel like: 1) Look up "this months current way of doing things" 2) have a couple of horrible hours wrestling with tooling and the module system 3) add a new feature, install 1 lib with 30 deps 4) figure out that one dep does not work with TS/the chosen module system/whatever versioning related thing 5) go for a walk. scream into the void. c…
But the tooling and the ecosystem are nightmarish! It's skin-crawlingly awful to set up a new project, or to update anything, or add any dependency. This is not TypeScript's fault; not really. But literally everything from the IDEs to the package manager to the output messages are awful. I can even add to your list:
8) ignore hundreds of lines of SEVERE SECURITY ISSUES because literally all of them are false positives all the time
9) deal with Visual Studio constantly crashing, throwing up 600 "build errors" because it doesn't like the standard DOM typing definitions
10) struggle for days to compile and package all the TypeScript files into a re-usable library; give up, and instead set up a script to literally copy the raw *.ts files around.
Typescript is great but be aware that sometimes it can annoyingly slow you down. Consider these scenarios: - You want to use a third party library but it is completely untyped - You need an object but you're just prototyping it. You don't yet know which keys will be optional - You type a key of one of your objects. Now you load or fetch data from an API and want to assign that to it. But typescript complains because…
If you don't know what parameters are optional, just add the little question mark to every variable and remove the ones that turn out mandatory? Better to have some type info than nothing at all. If you fetch data and TS tells you the result may be undefined then I guarantee you your code would've randomly crashed at some point in the future because of it. That error is a feature, not a bug!
Then I have to e.g. check if all keys of an object could be undefined before i do something with them.