Sell Me On Typescript
source link: https://dev.to/psypher1/sell-me-on-typescript-112b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Sell Me On Typescript
I'm a Python developer and this strictly typed langauges this something I left after I finished my Diploma (C, C++, Java)
I later got into React and all those web dev stuffs that the kids are into. At that time javascript was all you really needed. Then the wave of Typescript hit and everyone jumped on.
I get all the "advantages" of it, but in the past few months I looked into it and decided to rebuild my portfolio with it - the portfolio is still not done.
Most of my time was spent making Typescript happy and not building.
So, you Typescript pundits, why must I use it?
Discussion (70)
"why must I use it?"
You don't have to, but I think you'll learn a lot if you do.
^this
All I can do is to promise you'll thank every developer (including your past self) if they write their code with static types.
Don't like TS for typing? Maybe you'll prefer JSDoc: typescriptlang.org/docs/handbook/j...
Granted, I could have chosen better wording. Most of the times I come across people hyping TS it's usually "it'll make you faster". The way I work, fast is not a metric I focus on. But using that, I have spent more time doing something in typescript than I would have if It were just JavaScript.
It's not that I don't like it, I'm just not convinced more than anything. JSDoc you say, I'll have a look at it .
Thank you
I like the idea of JS Doc TS but in my judgement you have to be good with TypeScript first before trying to tackle JS Doc TS (and it has an even larger hurdle for initial setup). The best JS Doc TS example I know of is Preact.
Rich Harris@rich_harrisMoved some of my smaller libs to JSDoc TS; thoroughly recommend it. Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code twitter.com/swyx/status/13…13:34 PM - 16 Jan 2021swyx @swyxInteresting counter-trend - maintainers of large open source projects like @Sveltejs and @Deno_land are moving *AWAY* from writing their internals in TypeScript
Just at the same time when the wider dev world is falling in love with TS.
Reasons: build times and code complexity. https://t.co/a74GAoYhwp
Thread
Thread
Most of the times I come across people hyping TS it's usually "it'll make you faster"
The thing here is - it does make you faster on 'common' development projects. This implies, you:
- work in a team
- have a dev workflow including code review, exhaustive testing, and so forth
- re-write a bunch of features in each sprint phase
I think not being convinced is okay. My portfolio is written in JS as well. And I see no good reason to rewrite it just for the sake of adding Typescript to the codebase. The last two hackathons on dev.to, I wrote using Typescript. I didn't work on them regularly. Since they use several layers of abstraction, VSCode's TS intellisense was really helpful to understand
- function / method argument types
- return value types
- how to instantiate a class
- getters from Pinia
That's what I meant about the "you'll thank every developer later" part. The less mental capacity you use memorising what you built earlier, the easier it is to plan what to write next. Or whether you can re-use or refactor your modules.
Thread
Thread
This makes sense. When I do work on a project that uses it, then I'll dedicate more time to. As of now, I don't have a valid reason...
The whole affair drove me to build the portfolio with Eleventy instead - to actually see what javascript is necessary for it. For that, I'm grateful
Thread
Thread
Last time I checked there were additional hurdles to using TypeScript with 11ty.
Enough for me to consider using Astro instead if TypeScript was a critical consideration.
Thread
Thread
Oh no, Eleventy was after... I was initially building in Next.js with TS..
Then the TS thing made me decide to forgo frameworks altogether
Nope, definitely not faster but safer.
CollapseExpand
My recommendation would be to not let it slow you down. Make good use of the typescript config file, ensuring that the strictness is calibrated to the level you need. It's phenomenally productive to catch sneaky bugs at compile time, even if it may not seem that way on the front leg of dev.
The awesome thing about the ts-config compiler options is that you can scale them up over time. The goal is to have full strictness enforced, but if and when that slows you down then by all means dial it back. The goal is DX and developer productivity, it just so happens that specifying types at compile time do allow for huge amounts of preventative measures
See, no one ever mentioned this to me - that I can choose how I want to work.
I will look into making it work for me and not the other way around.
This makes more sense
I'm not particularly fond of TypeScript - overall I view it as having poor ROI but decided to learn it anyway so that I could at least have a somewhat coherent base to criticize it from.
That said I accidentally fell into an interesting work flow. I was trying to use uvu with TypeScript. It uses tsm to test TypeScript code.
With that setup you can actually focus entirely on getting your unit tests done first without paying any attention to TypeScript - type checking (linting) only occasionally when the test results don't make any sense (i.e. overall the tests where more effective pointing out issues than TypeScript).
Once you're done with a unit of work you can then focus on what TypeScript is complaining about - "oh yeah, I better clean that up".
That allows a "JavaScript style" work flow with (a sprinkling of) explicit TypeScript types for documentation.
Basically use fast non-checking transpilation with a fast loader for reqular work and only run the full type check at the end or when things get weird.
Thread
Thread
Not sure what you are hoping to find but recently I put together solid-hackernews-a.
Vite uses esbuild for "discarding type annotations" - so npm run dev doesn't type check (presumably that is supposed to happen a priori in the IDE/language server enabled editor). npm run lint:types is used separately for static type checking.
Thread
Thread
Not looking to find anything specific. I understand technologies better by having a look at how people use them over reading the docs...
I'll have a look, thank you
CollapseExpand
Once you get the "hang of it" you won't be battling with it. It will become second nature to build variables and type them.
By doing so you won't see as many type errors and such. It's just a learning curve. Persevere and you will seen the benefits !
I'll keep at it, without a doubt... I wanted to hear what other people say about it
Thank you
There is a reason VERY smart and accomplished developers, that can code circles around any of us, created Typescript.
Thread
Thread
You'd never catch up anyways 😉
CollapseExpand
TypeScript has a fairly large learning curve (I would say larger than some real statically typed languages like C# and Java) and it WILL slow you down on small projects. It's also easy to use TypeScript poorly, and not get much benefit out of it, if you just throw any at any sign of a problem.
But when you get into large projects, especially when you're working with other people, it will accelerate you and make your code better (if you use it well, anyway). Refactoring gets much easier, intellisense gets much better, you know what kind of data you're working with.
Some people are all-in on TypeScript and use it for everything. I'm not one of them - I find it a waste of time for relatively small, personal projects. But I'd never consider using plain JavaScript for anything substantial anymore.
Oh yes the any thing was the first thing I took to heart when i watched Jack Herrington's series. To that effect, i understand not to throw any everywhere
This is understandable, thank you for the explanation
CollapseExpand
You should only use typescript if you care about the mental wellbeing of whoever has to maintain the code after you're done with it.
Btw, you can always make typescript happy by typecasting to unknown firsts and then any. Not saying you should do this in production code, because you essentially lose all the benefits of typescript if you do this, but it can be helpful while learning. Once you get your code running, you can revisit the ugly type castings and determine how much time you want to take to "fix" it (spoiler: its usually much easier than you think and gets even easier as you learn more about the typescript typing system).
It also helps to use packages that have proper typings, or that have associated @types packages. You don't usually have to do any typing when packages are properly typed.
Oh and another thing people usually run into:
type SomeType = {
foo: 'bar'
}
function helloWorld(param: string) {
const myObj: SomeType = {
foo: param // Type 'string' is not assignable to type '"bar"'
}
}
function helloWorld2(param: string) {
const myObj: SomeType = {
foo: param as 'bar' // You have to use string literal "bar"
// You can either type cast, or change the type of param from string to 'bar'
}
}
CollapseExpand
My argument for typescript has 2 parts:
- intellisense benefits from the definitions as you write them, and it paints a picture for other developers that come before you (though I know jsdoc can do this as well, it is easier for developers used to strictly typed languages to adapt)
- many of the features of typescript come out long before javascript adopts them, so it has a great track record of predicting what javascript will do. Having a head start on newer patterns gives you an advantage when the world eventually phases out typescript and leaning into most of its features.
My own personal reasons for using typescript involve being able to be self-accountable and make sure all the contracts I write with the code are properly handled. It can give you some freedom when writing internal code, so you don't need to necessarily write tons of runtime checks on the data since you know the compiler will check for a lot of that. The only areas where data checking is really important in typescript is when you have an external data source (or input) that could come in during runtime that can possibly not meet the structure contract. As you adapt to the nuances of the flavored language, it gets easier and faster to build.
The biggest evidence of your struggle not being with the language is that the code you write does not obey the rules you write, so its more of an issue of how you are writing the code, not with typescript itself. Think of it like training wheels. Eventually with enough coding in typescript, writing a specific way will become second nature and you can take those practices with you into JavaScript.
Contacts? Web3?
I'm not foreign to typed languages, Typescript has just given me more grief than the other ones.
I wanted to understand the increasing adoption of it
For many, the fact that javascript isn't typed keeps people from working on web projects, and typescript was a way to bridge that gap. Being that it was developed by Microsoft, perhaps it was developed to bridge the gap between C# and web so they could reuse developers from backend on frontend to a degree, for familiarity.
CollapseExpand
You do not "have to" use it. You would use it, because from what it offers on top of JavaScript you could think it is worth it. There is no need to use it, because you "have to". Typescript bascially is just an extension of JavaScript and allows you to use strict typing, which would make it comparable to lanuages like C#. Editors can make use of it and make development easier (show you allowed methods etc.) as well as allow you to integrate these types as a kind of "rules", which will lead to code, which does not get built, if you break these "rules". There would be no error during the execution in this specific cases, if you could not use it this way. If you want to use some of these points, which I just have described, for your project, you can see them as a must.
But you are not forced to used it and if you are still learning JavaScript, then stick to it for some time before you add with TypeScript to the language's complexity (my opinion at the moment).
Yeah, I'm noticing my wording could have been better (writing while tired)
My question was more on the "why" I see a number people advocating the switch to it. My question comes as my JS is solid enough to do what I need, so why would consider adding TS to the mix is all
Thank you for the elaboraion.
But I am also sorry, if my answer has been too serious. Thanks for your kind response.
Thread
Thread
It's alright... I got your thoughts as well as valuable information - which was my intention.
CollapseExpand
Adding types to your code in general is tremendously helpful when working on larger projects, regardless of the language. I've found static analysis tools like Psalm incredibly useful in PHP as well - it's found an awful lot of problems in legacy code.
There's a few options for adding types to JavaScript and while I have used Flow in the past, and still prefer it conceptually to the idea of a whole new language, the tool support is significantly better in Typescript. There are some things Flow does better (opaque types are frustratingly still not a thing in Typescript), but overall Typescript is the better experience.
CollapseExpand
Typescript is simply the same Javascript but extended with typing, but not only that. You’ll become better JS dev, with the full picture of this technology whether you use it widely or not, OOP, style of coding, tests, security, new features (ES2022..) and etc.
CollapseExpand
for frontend, i don't think it requires that much of types except when you are passing different data throughout the components and for the back end it becomes incredibly useful when you are able to look up what you need to pass and in which format
CollapseExpand
Well I don't know.
On one hand I love static typing. In Rust or Kotlin, it takes you by the hand and helps you figure where you are and what you are doing. Very useful.
There is also the case of typing annotations in Python which are super useful for the same reason. I write them all the time and it's no bother at all.
But then when I try TypeScript I feel like I'm fighting against the world. The whole JS world is not built around typing and especially inputs from the API. Taking in all this external data (which let's face it is the largest chance of getting a typing problem) is always super tricky.
On the other hand I'm using Vue and PyCharm, which handles Vue super well so all the auto-complete basically just works without me having to take care of annotating anything.
Not sure what to make of that. JSDoc is indeed probably a better way to go. Getting 99% compliance (JSDoc) is easy but 100% compliance (TS) can be a fucking pain in the ass.
CollapseExpand
Just another layer of crap that's not needed in most project's.
Maybe if your project is crap. I build enterprise grade software for banks and hospitals.
And yet there are thousands of Enterprise grade websites out in the wild that don't use typescript. Use if you want to, don't use it, I really don't care, I personally have no use for it (as of now, that may change). Not enough benefit for the cost, I have bigger fish to fry like Rust and Flutter, which I think are a much better investment of my time, but that's me(others may disagree and that's fine). In the end it's nothing more than a personal choice.
Happy Coding
Thread
Thread
Just because thousands of companies do it doesn't mean it is correct. Nor that they wouldn't benefit from static typing. Thousands of companies still hire terrible offshore developers that use JQuery too 😂.
I'm talking about static typing not just Typescript. There are times where it matters and times it doesn't.
I'm not saying it is always needed but most developers suck so I think it often has value.
Rust and Flutter are both statically typed. So you do appreciate static typing 😊.
Thread
Thread
This I understand, I had specifc questions in reagrds to Typescript is all
CollapseExpand
Have you tried typescript yet ?
What was your experience like ?
After trying out typescript by building some toy project, why on earth would you go back to using some awful alternative like flow or even @JSDoc
Yes, I ask because I have tried it and what I am looking for is more information
CollapseExpand
The primary value-add that I have found with TypeScript is that its features add quality controls to your JavaScript project.
Is it necessary? No, but the value does become evident when an active project scales in complexity and age.
One of my active SaaS products is a Node.js app that started in 2012. Little/no tests, callback hell, and enough features to sell to the enterprise. When I was the team lead on that product’s mobile application, I would have to remediate bugs several times a year when a team member building features for the web modified a shared method and removed/modified an output. If we had types (or tests tbh) around the method’s I/O contract then it would have been caught before merge.
Additionally, callback hell paired with an architecture that IDE’s didn’t fully understand meant significantly more time mapping out process flows within the application. I had to do it a couple times when turnover left me as the one responsible; those efforts took several hours over multiple days, often repeating the exercise multiple times to validate the flow was accurate.
Today, I write all of my application source in TypeScript for new projects if I’m building a JavaScript runtime, but some things like Grunt.js are still authored as regular JavaScript
Thank you so much for explaining in this much detail. This kind of information is what I was looking for.
This question was shared on Twitter and some of the responses there were discouraging. If i was starting out,I would have given up on it entirely.
CollapseExpand
Hey learn brainf***, teaches you something .. there is nothing you have to, but code is just a lot nicer to read and you can avoid some bugs easy ..
nice sarcasm. You don't have to comment either. You completely missed the point... Too many junior Javascript-only front-end developers here that obviously haven't worked on large, critical code bases. They like to stick to what is easy and familiar. Typescript is frustrating because it is difficult and catches errors. Maybe your ego is too big for that. Cheers!
Great minds discuss ideas; average minds discuss events; small minds discuss people
Thread
Thread
And tiny minds keep commenting . . .
CollapseExpand
"why must I use it?"
You don't have to, but I think you'll learn a lot if you do.
"Most of my time was spent making Typescript happy and not building."
That's great! That means you were removing potential errors and fragility from your code. It means you're learning or at least getting the opportunity to. New Rust developers go through the same thing; Rust's compiler is very strict.
Static typing is like an automatic book editor that checks for spelling and grammar errors and plot holes. Why would I need a book editor for a few paragraphs or a few pages I write on my own? Surely, I'm a big boy and know how to spell and write a coherent story. Now imagine you're one of a dozen authors simultaneously writing a 100 million word novel, it isn't so easy anymore.
Tools like static typing feel cumbersome and pointless to junior developers because the benefits aren't all the apparent at a small scale, just like software architecture. I always say that popsicle sticks and blue are much easier to build with unless you want to build a house or skyscraper.
Historically, statically typed languages were very verbose (I'm looking at you Java) and had cumbersome type systems that weren't all that expressive. They didn't even have type inference. So dynamically typed languages offered a lot of freedom but less security and guarantees.
So, I won't sell you on using it but I think you can learn a lot by trying it, especially on a larger, older codebase with more developers. That's really the only way to grok the benefits without understanding them at merely a theoretical level.
I'm moving from Typescript to Purescript for my personal projects, mainly for the added compile-time guarantees.
Hope that helps. Cheers!
CollapseExpandCollapseExpand
In a nutshell, TypeScript is a strongly typed programming language that builds on JavaScript and this is so nice!
CollapseExpand
Which clearly shows you don't understand the benefits of static typing. Catching type errors is only a small part of it.
Imagine refactoring all that JavaScript. You're just doing find and replace like it's 1995.
Furthermore, you can model your domain logic into types which become type errors.
Purescript is much better and has a sound type system.
Saying static typing isn't helpful is like being so cocky to think spelling and grammar checkers are worthless.
To each their own I suppose.
CollapseExpand
Seems like there are two camps 1. The haters and 2. The lovers of TypeScript.
I'm a lover of it for one major reason Intellisense. Ok two reasons, compile time errors instead of runtime errors.
Runtime errors and lack of intellsense are prehistoric.
Most haters have very little experience and are JavaScript-Only developers. If "catching bugs" is their only reason then they clearly don't understand it.
When I do pair programming I often see Junior developers get type errors. I've seen large code bases fail to compile because the crappy team couldn't even write code that compiled.
It helps with refactoring, modeling business logic and for new developers to understand how to properly use a function.
Thankfully if the code didn't compile I didn't allow it to be merged (love DevOps). I remember getting screamed at for that 😂.
I hear you Brother. I've been told right here on Dev.to that I'm dumb, stupid, illogical, and many other pejoratives. They all were Javascript only purists who even denounced their own language adopting classes. These are the same folks that write 5,000 line mono repos filled with magic strings who don't follow DRY. Talking about insanity.
Thread
Thread
Yup. Those purists will never make it long-term.
I recently used Typescript for the first time on a large codebase. Wow, ramping up was so easy. I had type information for everything. Plus, refactoring was a breeze.
I currently use GraphQL code gen to generate my Postgres schema, types etc all from my GraphQL schema. It's all type safe, auto-documented and beautiful.
CollapseExpand
IMHO TS itself does nothing else then clears a bit of context of our code.
If you don't know js but came from any other strongly typed language, it helps you to understand what's going on with typeflow - assuming the project is properly typed - and gives you some insights of the surroundings, like it's typed for node or browser env.
But to really make code that is efficient and consumable, discoverable you still have to understand javascript, since it is just a superset of it.
CollapseExpand
Dont use TypeScript unless you know how to use it. When you do some lessons / courses and can use it fluidly to create apps. Then you know why you use it.
TypeScript is absolutely essential in coding. As you secure the flow in your app. What you gain with TypeScript? Debug time is lowered immensely. As you cannot basically make big errors.
Websites/Javacript ran just fine well before typescript came along, so the notion of typescript being "absolutely essential in coding" is questionable.
CollapseExpand
I believe you should not be "sold" on technology. You should choose whichever you would like to use, whichever fulfil better your goals and help to achieve it.
Sometime make sense to work with TS, sometime simple JS is better. Sometime should be plain ansi-c, sometime Java.
The real question: why do you wan't to limit yourself and select between?
CollapseExpand
I am a die hard TypeScript fan. But not because of TypeScript; I am a die hard fan of it because of types.
At first, it will definitely slow you down. The equation is simple: if you start writing Rust now, you'd be way less productive than you are with Python, for instance. That's not exclusive to TypeScript. But once things click in you head, you won't look back.
In the long term, I think types give you more critical thinking on how you code. That means less bugs, greater developer experience, hence better productivity. In the end of the day, TypeScript is something you'll only find value once you really feel it flow.
But in general, I think TypeScript's benefits (or really, static types benefits) can be summarized to:
- Greater Developer Experience,
- You'll be more confident to scale your app,
- You'll be more productivity to model your projects all around.
That said, I'd say TypeScript is far from being required for small projects. Your portfolio, for instance - you definitely don't need it and barely will feel its benefits, regardless of how proficient you are. But if you are willing to scale your portfolio's features, then I'd say it's a great call.
CollapseExpand
The cost of learning and applying typescript is quite high. It will slow you down at first.
The main early benefit is type safety and intellisense. But it often feels like it's a lot of work for little gain.
But in my experience, you reach a point where you suddenly find yourself moving much faster, having way more confidence, and then you'll join another codebase in javascript and you'll realise how much you lose when you don't use static typing.
CollapseExpand
My bias: huge TS fan here, since the pre-1.0 days.
My first thought is that there's definitely a learning curve. I would say this is the only real disadvantage to typescript, if you aren't already proficient with it (and the latest versions of typescript are quite sophisticated type systems), even if you're well educated in static type systems generally, it's going to slow you down for sure. You're going to struggle with annoying error messages and compiler problems that you know aren't real runtime problems. It sounds like this is what you've run into. I myself hated the idea of static types in front end code originally for the same reasons. I know it's not much of an argument, but I would just say stick with it and once you're proficient enough you'll wonder how you ever wrote JavaScript at scale on teams without it. That's my story and the story of nearly every typescript naysayer I've ever worked with. Just anecdotal but there ya go, happy coding!
CollapseExpand
Refactoring is a breeze and it'll help catch dumb mistakes that you will see no matter what after bundling so in that sense it can save time or make you a more efficient developer. I personally hate that we rely on transpilers but it's an implementation detail for now. Hopefully we'll get static typing in JS and TS can go away.
The setup is actually easy if you study the TS rules for the compiler, don't take it in all at once, there's so much utility to it. Plus you get to incrementally upgrade your project to TS so it's not an all or nothing.
CollapseExpand
where do i start...
Making "Typescript happy" is making your code happy & avoiding errors down a line. I can see why that is annoying on a small projects, but when project grows there is no way you gonna avoid errors, and most of them will come from the wrong types, incorrect params and so on... You can avoid all of those ( most of it ) with TS.
Having auto-complete is one of the best feature with TS.
In the end, you don't have to use it. For a small project it may even be noth worth using it. But i thing ones you extensivle use it in one project, there is no going back.
CollapseExpand
I moved to TS about 3 years ago. I never looked back.
The ability to work in a pseudo typesafe environment is an absolute game changer and will make your code more robust and easier to iterate on.
It will also force you to do more "engineering" vs simple dev. Needless to mention that I would write many tests which have now become obsolete.
CollapseExpand
nice jucie auto complition
CollapseExpand
If you are just making small web applicatins or wrting simple scripts, JS is all you need.
CollapseExpand
Simple: catch bugs early on during development. That's it, sold :)
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK