Should i use typescript?
Answered
Anay-208 | Ping on replies posted this in #help-forum
I’ve heard big projects are ditching typescript.
Mainly due to code readability, and compiling step.
Mainly due to code readability, and compiling step.
Answered by Z4NR34L
we can tell you here only things that we had done/seen or experienced, there is no universal advice to use or not typescript, just like @risky said - you need decide what YOU want 😄
23 Replies
For compiling step, what is the problem for that in some companies?
well configured typescript prevents many runtime and server errors as well any types being not compatible with components etc. 😄
We had migrated internal project's whole codebases to typescript to prevent such situations when something is not visible due to types mismatch.
We had migrated internal project's whole codebases to typescript to prevent such situations when something is not visible due to types mismatch.
@Anay-208 | Ping on replies I’ve heard big projects are ditching typescript.
Mainly due to code readability, and compiling step.
for context, what are you building? if nextjs (this server), then there will be no benifit on built time... but imo its still better (but i don't work in mega corp)
and yeah typescript imo makes it easy to know what is changed and throw errors to let you know
@risky for context, what are you building? if nextjs (this server), then there will be no benifit on built time... but imo its still better (but i don't work in mega corp)
I’ll be building e-commerce sites in the future
and using what?
Nextjs
then your only "potentially valid point" is code readability as comp step is already there...
Let's visualize it that way - if something is mission-critical like medical software, you just won't risk someone's life to save 2 seconds on build time 😄
but i prefer a little typescript than code comments or needing memory to know what things are
From my current experience I can just add - with typescript you will spend less time on debugging run-time issues 😉
@risky then your only "potentially valid point" is code readability as comp step is already there...
i think in the builder, as it needs to be built anyway, it has basicly no impact (just a little ignoring of code)... the decent reason is if you don't need any step...
I can't live without typescript
and with things such as bun, you even less need to use tsc before running (this isn't nextjs tho)
i tried jsdoc, but it wasn't the same as just ts... ts was just way better (but jsdoc was better than nothing)
and in the vid he quoted "type gymnastics", but my opinion is that you don't need to go crazy and using more generic types are fine... you don't need to make a really complex type...
anyway, its really up to you and you should do what you want and not the latest craze...
But still IDEs like jetBrains IDEA can extract types by itself basing on fetch response for example 😄 So just remember key bind for that haha
@Z4NR34L Let's visualize it that way - if something is mission-critical like medical software, you just won't risk someone's life to save 2 seconds on build time 😄
I’m still not sure then, why are big projects doing it for compiling step
we just can't generalize that all projects are doing that - in such case Rust Lang will be dead 🙂
we can tell you here only things that we had done/seen or experienced, there is no universal advice to use or not typescript, just like @risky said - you need decide what YOU want 😄
Answer
@Anay-208 | Ping on replies I’m still not sure then, why are big projects doing it for compiling step
Hierran Wolfdog
There really aren't that many projects that are doing it, and you'll notice the ones that are doing it are libraries, not applications. Libraries can get away with it because you usually don't really care about how a library works under the hood, just that the api it exposes is nice to use and works well, which can be achieved by shipping a .d.ts with your lib generated by jsdoc or something. For an application though I would say it's more worth it to use TS to prevent a bunch of otherwise easily avoidable errors.