One of the things that I like most about TypeScript is that it is a superset of JavaScript. This means that any valid JavaScript code is also valid TypeScript code. This makes it very easy to get started with TypeScript. Another thing that I like about TypeScript is that it has static typing. This means that you can catch errors at compile time, rather than at runtime. This makes for much more stable and robust code.
One of the challenges that I have faced while learning TypeScript is understanding the type system. The type system in TypeScript is very powerful, but it can also be quite complex. It has taken me some time to get a good understanding of it, but I am still learning new things about it all the time.
Overall, I am really enjoying learning TypeScript. It is a great language that has already helped me to improve my JavaScript skills. I am looking forward to continuing to learn more about it and using it in my future projects.
What is Typescript?
TypeScript is a free and open source programming language developed and maintained by Microsoft. It's a typed superset of JavaScript that compiles to plain JavaScript. TypeScript adds optional types, classes, interfaces, enums, generics, and more to JavaScript. These features can be used by the TypeScript compiler to provide type safety for your code. TypeScript code can be compiled to ECMAScript 3, ECMAScript 5, or ECMAScript 6 (also known as ES2015) code.
If you're familiar with React, you may have used the createreactapp CLI tool to create a new React project. The createreactapp tool uses TypeScript by default. This is because React is developed using TypeScript and it's recommended that you use TypeScript for React projects.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. It gives you type safety, objectoriented programming, and other benefits that the JavaScript language lacks. If you're familiar with React, you may have used the createreactapp CLI tool to create a new React project. The createreactapp tool uses TypeScript by default. This is because React is developed using TypeScript and it's recommended that you use TypeScript for React projects.
Why I'm Learning Typescript
I've been meaning to learn Typescript for a while now. I'm finding it really helpful in understanding JavaScript concepts, and it's also just really fun to use. I'm looking forward to using it more in the future.
I first heard about Typescript when I was looking for ways to improve my JavaScript skills. At the time, I didn't really understand what it was or how it worked, but the idea of being able to type out my code and have better control over my variables sounded appealing. After doing some research, I decided to give it a try and I've been hooked ever since.
Typescript is a superset of JavaScript, which means that any valid JavaScript code is also valid Typescript code. This makes it easy to get started with, as you can gradually add Typescript features to your existing code base without having to rewrite everything from scratch.
One of the things I love about Typescript is that it forces you to be more explicit about your code. For example, if you try to access a property on an object that doesn't exist, you'll get an error. This might seem like a pain at first, but it actually saves you a lot of time in the long run by catching errors early on.
Another great thing about Typescript is the support for type annotations. This allows you to specify the type of a variable, which can be helpful for catching bugs before they happen. For example, if you have a function that expects an number as an argument, you can annotate the function with:
function(num: number) { ... }
If someone tries to call this function with a string instead of a number, they'll get an error telling them that they're using the wrong type of argument. This is extremely useful for catching errors in large codebases where there are many different types of data being passed around.
Overall, I'm really enjoying learning Typescript and I'm looking forward to using it more in the future. It's helped me improve my JavaScript skills and has made me more aware of potential errors in my code. If you're thinking about learning Typescript, I would highly recommend it!
How I'm Learning Typescript
I'm currently using the TypeScript Deep Dive book as my primary resource for learning Typescript. This book does a great job of explaining all of the features of Typescript in a clear and concise manner. Additionally, the book includes a number of exercises that help to reinforce the concepts that are being taught.
In addition to the TypeScript Deep Dive book, I've also been using the official TypeScript documentation as a reference. The documentation is extremely thorough and covers every aspect of Typescript in great detail. While it can be a bit daunting at first, it's a great resource to have on hand when you need to look up something specific.
I've also been making use of online resources such as the TypeScript Playground (https://www.typescriptlang.org/play/) and the TypeScript Handbook (https://www.typescriptlang.org/docs/handbook/). These resources are extremely helpful for trying out code snippets and seeing how various features of Typescript work.
Overall, I'm finding that learning Typescript is not as difficult as I initially thought it would be. With the help of some great resources, I'm slowly but surely getting up to speed with this powerful programming language.
Top comments (55)
Hi @annabaker ,
About that:
Create react app is NOT using TS by default neither they recommend nor reject TS, because it has no sense. It's not their competence as library, to define which other dependencies you need in the whole project.
It's an option to choose by the developers (usually the TL or LD) taking in mind the specific use-case and it has many pros but some drawbacks as well.
While TS brings some advantages, still JS is the most used in the whole world* and it's in backend where it shines most (Node JS, Deno, Bum...) IMHO.
If you want to use create react app executable along with typescript you need to explicitly state that by using:
Or the yarn equivalent:
Otherwise it will be JS (without TS).
Despite that, it is not recommended to use create-react-app executable for other thing than learning purposes. It is boilerplaty and with all probability will add dependencies that you may not use. It's better to add the dependencies (react, react-dom, a bundler like Webpack or Parcel, jest...) When you're about to use them than using the create-react-app and then start deleting things when you realise you're not using some of them.
Maybe you prefer (or need) Parcel because it's -almost- zero config, or using a different testing suite than what comes along the executable or... Whatever.
As bonus there is more than one way to use TS:
To TS or not to TS, that is NOT the question. Is it?
JoelBonetR ・ Apr 26 ・ 4 min read
Best regards! 😁
*You can search jobs with TypeScript keyword in LinkedIn with some desired filters (or not) and then do the same using JavaScript instead.
Even that I also think that learning TS is a good thing (you'll be able to work in both JS and TS and, using what is explained in the embedded post I added, it will be almost the same with few exceptions).
Thank you so much for your comment! I will check it out!
Hi, its me again, just here to point out again that typescript developers are all also using JavaScript, which is why JavaScript is the most used language... Typescript= JavaScript+ types
And you can look at many trends showing that typescript is by far the most used type system language for JavaScript :) not your weird jsdoc nonsense :)
Of course TS is the most used type system for JavaScript, but that's not the reason for JS being the most used language around the globe.
All TS projects are also JS projects but not all JS projects are TS.
In addition, TS pragma is also TS, and JSDoc has been maintained by TS guys as well in case you didn't know: typescriptlang.org/docs/handbook/j...
Hope it brings some light, like it or not.
You keep repeating "javascript is the most used language" as an argument against typescript... But I guess you're never going to understand how stupid that makes you sound... I'm honestly just here to point it out to others, I realized you're a lost cause several months ago. 2021.stateofjs.com/en-US/other-too...
Oh, just to point out... Literally only 16 out of 11258 respondents to that survey said they strictly use vanilla javascript. I guess there's 15 other people besides you who are insane :)
It is not against TS, honestly. As I said it's a good thing to learn and to use.
But I'm also honest and realistic about the current state on the market, where there is more projects without TS than with TS. Thinking the opposite is just neglecting the truth of the market.
This is changing though, not as quick as we expected some years ago, but I expect either TS being on the TOP of the state of the art in a couple of years or JS bringing those desired features in the core API while making TS "deprecated" or included in the spec by the TC39 (we'll see which proposal is admitted and in which way as there are some of them, including TS itself).
The JSDoc along with TS pragma has proven to be a good approach on three situations;
1- You want to migrate a code base (of any complexity) from JS to TS. By adding JSDoc and TS pragma you can get static typing, type checks... without having to rewrite the code. Still providing full compatibility between JS and TS along the process.
2- You understand the benefits of static typing buy you also think that using TS has more drawbacks than what it really has (by lack of experience) or the realistic drawbacks that came along with TS (dev time, specifically) can't be justified for the requirements, budget etc.
3- You have a new project in mind but none of the devs (or the major part at least) have previous experience with TS and/or they are not interested on it.
I know you'll tell that either be the case, go ahead with TS and most of the time you'll be right.
Still there are situations where you won't, and in such cases, IMHO is better to use TS Pragma with JSDoc than not using neither TS nor this approach.
If you notice that I try to make more people to know about that is just for that reason (as we discussed before).
An important part of my job is to choose tech stacks accordingly to the business needs, which is not necessarily what I want to use. Despite that I'm not paid to bring my likenesses over the table but to find what aligns better between the business (client) and the available resources (devs).
If it's TS, go ahead with TS, if it's plain JS, it will be plain JS (but I'll encourage the team to use TS Pragma with JSDoc and add it as requirement in the code) so any future migration (if any) will be much easier and we benefit from the features it brings in the meantime.
Oh please, you're constantly advocating for using JSDoc over TS. You're not fooling anyone claiming now that you're unopinionated and "choose tech stacks accordingly to the business needs". The reality is: you've never chosen TS for that tech stack. The fact you're pretending otherwise right now speaks volumes. Deep down even you are realizing you're being obnoxiously stubborn and that the whole world has moved on to greener pastures.
You should create a post around that stuff, your opinions, likenesses and the reason (if any) behind them instead creating threads larger than the main post in others articles.
You think it's me being stubborn and neglecting the current state of the art and I need to point you again the metrics we care about, which are less than 24k open job positions around TS in the entire European Union vs the over 65k in JavaScript (LinkedIn, searched just now), or the 5.3k vs over 13k if you filter by remote only. If we move to US market it's much much worse for TS.
No survey answered by few hundreds (not necessarily developers) can compete agains that, like it or not, believe it or not (you can search it for yourself in 2 minutes).
You can lie to yourself and say "TS is JS" and it's not. Any JS is valid TS code but not a single line of TS (other than comments) is valid JS.
TS is not so widely used as you think or as you'd like. Sorry. I also find it useful and a must in some projects (not in all of them of course, I'm pragmatic, not a fanboy) and I show people a way to introduce themselves in TS or Typing JS projects with the pragma+comments approach.
I'm wondering what do you do for the industry or for your beloved TS.
Create posts, teach people the basics on an easy way, or teach advanced concepts so we all can learn more and become better developers, do something, show off!
Arguing with others and trying to "change the world" without even trying to understand why it works the way it does is a nonsense and a lose of time.
This right here... Shows you do not know what you're talking about.
You live in the past and for some reason are scared to learn Typescript and so you try to convince people on a dev platform not to use Typescript by trolling each and every post about it.
That should be then 😂
@Rense Bakker
try to run your TS file in a browser without compiling to JS. Also there are no plans to support that in a browser.
Typescript extends JS by adding types.
And yes there are benefits using TS.
The downside is that some developers are not aware that your code still can fail on production. I see by getting data from (external) api which is unexpected type, missing. The code breaks on production. Because there are trusting on mockData and TS.
Yes the problem comes from the api. But still your code needs to catch it instead breaking.
There is a proposal to adopt type notation in JS
Without JS no TS
@Rense Bakker
one more thing what we can see a lot in code, when using TS. Is typing to any to avoid TS error.
Just adding that there are multiple proposals for adding optional type notation into JS core API (including TS itself, Flow and others) but AFAIK none of them reached a stage to be considered a possibility in the short term.
Another issue I faced one time (but I bet is not the only place where this happen) is being on a project where they had budget either for using TS or for applying TDD... They choose TS which is an aberration if you advocate for quality. Also two things happen: an imminent lack of confidence in the code in the short term and tech debt growing quickly. (This is not usually perceived by core team till the exact point where some devs start leaving and new ones come in).
Thinking that TS will magically convert your code into good, robust and trustable code is just ridiculous.
It has benefits and I expect a growth in the amount of business asking for TS in their open job positions because TS + TDD is usually better than JS + TDD.
You own personal interpretation, because community never said that, you are free to use whatever you need to. For instance, in my web company (>500 employees) we do use JS (Vue, corporate framework, etc) because no one except couple of guys (me included) knows TS, so it’s definitely not a good idea about using it widely. Hiring engineers with TS skills isn’t/wasn’t a main task.
That's currently the mainstream, specially in frontend 🤷🏻♀️
Wasn’t talking about trends..
Neither do I, it's just the current state of the market since long time ago.
Trends are spikes in between that and they may cope the market till certain point (see React for example, with more users than Angular, Vue and Svelte together) or set a tendency growing steadily (like TS) or keep living in the community hype for some time without reaching a worth mentioning piece of the market (see Tailwind).
All of them are in a certain situation for good reasons.
Again, i wasn’t talking about it, calm down. Anna stated that “it is recommended to use..” not the case, you can use JS/TS whatever suits you the best. Period
I think the point is still valid. It is recommended to use Typescript where possible over Javascript. It does catch some issues at development time, provides way better feedback on variables and instances in your IDE (and it's 2022, who isn't using an IDE by now?), and it makes you think about the way you write your code.
Of course, as with anything there are ways round all of that if you really want to ignore best practices. You can use
anyfor pretty much all your type declarations, you can force wrong types in at runtime (which won't be caught by the transpiler), and you can just disable warnings given by your IDE.Typescript aims to enhance Javascript, and bring some more modern concepts to the language, such as you'd find on C#, for example. You don't have to use Typescript, but it's recommended that you do because it will make your life easier.
Agree, still the amount of things you can learn at once is limited.
In my experience with newcomers they tend to focus into solving warnings and errors on types (which need to be defined) and less into actually learning the language (JS) API, hence the delivery is poor and individuals last longer to be able to get to an efficiency point.
Learning JS first (if you do it properly, of course) allows people to focus on what's most important first (learning the language, the huge API and the quirks of the language) because with that you can do things, protect yourself from runtime errors by experience, and then move forward to TS to get all those extra benefits.
I can recommend to jump into TS directly if you already have experience with another language that's strong-typed such Java or C# to make things easier though.
I have noticed the opposite. Newcomers tend to focus more on Javascript, as Typescript is seen as more difficult and harder to learn. I've noticed this with plenty of other languages too. PHP has quite a similar aspect in that there are the traditional older approach to writing code with it, versus the newer approach with stricter typing and cleaner architectural thinking (this is going back over the past decade and more of PHP). There is some level of pushback from developers who've only learned the older way, who don't see any value in more modern approaches. Personally, having worked with a lot of other languages with strict types, like C++ and C#, I come down on the side of preferring stricter typing in "loose" languages, because it's one step towards writing cleaner code.
For Typescript, one thing that it does introduce with the transpiler is the option to ignore some quirks of Javascript. This is made even easier when you are using something like NPM to bundle any required polyfills according to your build targets. After all, why re-invent the wheel. We're not developing in the days where IE6 was running ramshod over the specifications, the browsers are much more closely aligned in terms of support for features. Sure, some browsers might not support certain things, like Chrome doesn't support MathML, and some browsers implement many things that aren't officially part of the spec (unfortanetely have to highlight Chrome there again), but by and large, we're in a better position that we were 12+ years ago.
Jumping to TS from a position of knowing another strongly typed language does make sense. Microsoft did take a lot of what they learned creating C# in their creation of Typescript.
Can i skip javascript and learn typescript instead? does it will be problem
Since TypeScript is a superset of JavaScript, naturally you have to know JavaScript first. TypeScript simply adds properties, specifically statically typed, to your JavaScript code, making it easier to maintain.
ok got it
No cutting corners you have to learn the fundamentals of the language first. It's like trying to learn React before you learned JavaScript 😂
LoL
It’s more like learning a new language without grammar and rules
Imho, ts is not a language. It's a "typing+" tool for js. And as such, I find adding some ts features into your js is good. Ts has a lot of obscure features, which I think do more harm than good. I think one should not try to apply all ts features religiously. But that's me
:o)One very big benefit of React (for instance) is, it allows you to use js / ts minimally, I find.
I agree, ts is a good tool, but that one should not try to use all of its features all of the time.
My reason for learning TS :
It's great that you're learning TS! I'm sure you'll be able to use it in many different frameworks and libraries. Keep up the good work :)
Hey!
Thank you for the article!
If you didn't see github.com/type-challenges/type-ch..., you can give it a try, it helped me a lot in the last several years. Especially helpful if you want to dive into challenges and learn more things in details.
The only thing that I didn't like is the lack of detailed explanation
Thank you so much for the kind words! I'm glad you found the article helpful.
I'm always looking for ways to improve my writing, so I appreciate your feedback.
Hi,
I also struggled at the beginning when I started learning typescript, it might be annoying at the beginning but now after 3 years of using it I'd never go back to vanilla JS, I simply love the fact of finding errors at compile time instead of finding them at runtime.
Anyway everyone should use it because it makes you think "better" on your code
You're so right! It can be frustrating at first, but learning typescript is so worth it in the end. It's helped me write much cleaner and more error-free code.
I also started learning typescript
I'm glad to hear that you're also learning Typescript it's a great language to know.
Is it correct to call TS a language?
Because the engine is JS, only before the engine runs it adds some checks.
Is zend framework or Laravel a language?
I think i will call TypeScript as Javascript Compiler Just like for C or Cpp There is compiler called mingw or clang
Take a look github.com/gcanti/fp-ts, more complex project with TS
Thanks I will :)
Thank you for sharing!
You're welcome!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.