281–290 of 469 posts
The technology itself had few issues like compilation time and inability to run the application locally because of reasons.
The new systems were so complicated that everything ended in neverending bike shedding.
The people pushing for "everything to be written in typescript including other teams tooling (aka pulumi)" were very unflexible crowd.
The previous system had few issues that could be solved with database indices.
It's soul crushing to work on these type of places where technology is used for the sake of technology instead of bringing some business value.
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…
What's Math.sqrt("hello")?
Sure, you _could_ use it to check that you aren't making obvious errors like this (but this seems constrained to the "convince me that it's worth it" level of functionality, as it is just a nice-to-have for an existing working pattern).
Where TS shines for me is that it ENABLES new ways of "ad-hoc" coding where it's no longer risky to just create "convenience objects" to represent state when prototyping/refactoring, since you can avoid specifying concrete required types across a load of middle-man code and compose types at each level. This enables the pattern of splatting (composition over inheritance) a bunch of inputs to your data together, and then routing them to the points where they are needed. This scales nicely when you introduce monadic fun (processing some data with children, or something delay-loaded) since your type constraints basically write the boilerplate for you (I'm sure co-pilot will make this even more so in the far future).
There's also the fact that your can have your back-end APIs strongly typed on the front-end via something like GQL or Swagger, and this saves a TON of time for API discoverability.
Is it worth it compared to what? Plain JS? Transpilation from a different language? Rust? Growing apples? I have used plain JS, GWT, and TypeScript. TS is an incredible improvement over the two others. The TS type system is excellent, very expressive and helpful. An important advantage you get from static typing is that your IDE has more information to work with and so becomes more powerful. If you code in a text edi…
try out dart, its much better than TS
Hoenstly, for production code, TS makes me sleep better. No matter how many tests you write, that one undefined object will get you at some point. TS helps to eliminate a complete set at compile time (as you know) and that's great! Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win.
I have the same feeling regarding Haskell, Elm and Swift, the latter I program in 99% of the time. I really don't feel like I get the same sense of security from Typescript, to be honest. Maybe I'm not using it correctly? I tend to lean more towards OP's opinion. I would probably prefer something like Rescript, but haven't looked much into it.
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…
I understand why JS makes this difficult to type because you can mess around with the constructor. But for normal every day code you just expect `this.constructor` on an instance of `User` to be `User` and it really sucks that it isn't!
Learn infer and extends and you will accept all the downsides being zen from the height of your highly well typed codebase. If you don't find the following compelling: type IsParameter = Part extends `[${infer ParamName}]` ? ParamName : never; type FilteredParts = Path extends `${infer PartA}/${infer PartB}` ? IsParameter | FilteredParts : IsParameter ; type ParamValue = Key extends `...${infer Anything}` ? string[]…
On the one hand, I like this very much. On the other hand, if I open a project and I see many lines of complex types that don't do anything and I have to understand these types to use them to fix some bug, I'm going to say words out loud that I cannot write here. I've seen projects where there were many lines of complex types and, after updating some dependencies, there were many type errors even though the project r…
With regards to TypeScript, any, unknown, never are perfectly valid types and plenty useful, just need to be used appropriately.
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…
If you want to follow along, the proposal to allow type syntax to be part of JavaScript is here:
https://github.com/tc39/proposal-type-annotations
(To repeat Daniel, there is still a huge amount of work ahead)
I worked in two different team in two different companies where a full rewrite of the core system was done in typescript. The technology itself had few issues like compilation time and inability to run the application locally because of reasons. The new systems were so complicated that everything ended in neverending bike shedding. The people pushing for "everything to be written in typescript including other teams t…
In my opinion, TypeScript is not only essential in the context of any professional project, but it features one of the most ergonomic type systems I have ever worked with.
There are certainly pain points with certain TypeScript features (e.g. enums) but any project that takes me longer than 5 minutes to write, I need type checking. If I can't be bothered with setting up tsc - and setup difficulty is a valid criticism - I just use jsdoc.
I have seen TypeScript take the heat when applied to JavaScript projects that implement multiple trendy programming paradigms. Often times the projects themselves are so complex that adding a type system requires type-kungfu. It's not the type system at fault - but a needlessly complex architecture.
Love TypeScript. Wish there was anything like it that compiled down to static binaries.