TypeScript has become extremely popular among JavaScript developers and more and more projects use it as the primary programming language.
Today, most frameworks or libraries have support for TypeScript, which makes it easy to use.
TypeScript Everywhere
JavaScript/TypeScript can be executed on every platform. You can now use TypeScript for all your projects without any limitation: one programming language to rule them all!
It also means you only need to learn one programming language for all your projects. For any senior developer learning a new programming language isn't difficult but the time to master one is time-consuming.
You only need to use one ecosystem: one package manager, one linter, one code formatter, etc. You only need to configure once and share it across all your projects. Saving you a ton of time ;)
TypeScript for Frontend
The most used framework to build user interfaces is React and Vue.js. Both now support TypeScript.
I'm a React developer, I won't be able to say much about Vue.js. But when I started to use TypeScript with React, it wasn't an easy process because I was doing two things:
- Learning TypeScript
- Applying TypeScript in React context
In the beginning, you'll definitively lose your time fighting against TypeScript. But, once you understand the basics, it makes your developer life much easier. It helps you to write better code with fewer errors.
I like to write small components and you should too if you want to make your React code more modular. By using TypeScript on top of React components makes the code easy to navigate and maintain.
You can check out some React components written in TypeScript at this React Boilerplate repository. You can start your React projects with all modern tools like React, Next JS, TypeScript, Tailwind CSS with great tooling like ESLint, Prettier and Husky configured for you.
TypeScript for Backend
In the past, you need to write in different programming languages for the frontend and backend. The backend was mostly written in Java, PHP, Ruby, etc.
It makes the development experience not so great and the developers need to do a lot of context switching between frontend development and backend. The experience wasn't unified.
Node JS made it possible to write backend code with JavaScript. You can now write your REST API in the same language as your frontend.
Not only do you get the same development tools for both environments, but you can also even share the same code between your two environments. You don't need to write the same logic twice.
There are some edge cases where you aren't able to share the code due to the nature of the platform. Some packages or some APIs can only work in the browser. So, you couldn't run it with Node JS. On the opposite, some packages can only work in Node JS. This case is extremely rare but you need to be aware of it.
I have also build a Serverless Express JS Boilerplate to quickly create a Serverless backend REST API faster with everything configured: TypeScript supports, Offline support, automatic reload, ESLint, Prettier, Husky, etc.
TypeScript for Infra as Code
Several years ago, I used to rent a dedicated server to host my full-stack application based on the LAMP stack. It wasn't an easy task to manually configure everything from scratch.
First, you need to install the dependencies, secure your server, update the configuration file, etc. The most annoying thing is to maintain it.
The Infrastructure as Code (IaC) was the ideal solution to solve this issue. It makes the process smoother using definition files. For someone with a developer background, you want to version control your infrastructure resources and remove the repetitive task when configuring several servers. The IaC is the perfect tool.
With recent development, a new wave of IaC has emerged where you can use your favorite programming language instead of using configuration/definition files. Recently, I started to use AWS CDK with TypeScript to define my cloud resources.
AWS CDK makes learning extremely easy: you don't need to learn a new tool and new ecosystem. You can still use your favorite JavaScript package manager, tooling and it works perfectly well with your favorite editor (my favorite one is VSCode 😜). Because I use it with TypeScript, I know when there is an error or when I misuse a function.
TypeScript for Mobile Development
With hybrid application and React Native, JavaScript isn't limited to the web application. You can now start building iOS and Android applications with JavaScript. So, you can now use TypeScript without any issue to create your future apps.
Unfortunately, I'm not able to share much about mobile development with TypeScript. In the past, I've done some native mobile development on iOS in objective-C (pretty old school, before Swift) but not on React Native.
If I had the opportunity to make a mobile development, I'll definitively try React Native with TypeScript because I'm already familiar with React and TypeScript. I hope it makes the process easier and smoother. And on top of that, I also want to use Expo, a React Native framework. The framework seems to be very promising and it's considering a NextJS-like for mobile development.
TypeScript for Machine Learning
Even if Python has a much larger ecosystem and community, you can also use TypeScript for Machine Learning. I've built a small OCR using React and Tensorflow.js for digits number.
The user can draw any number on the screen and the application can guess the input. Here is an example:
It's possible to train the model directly inside the browser, but the result wasn't great. It was slow to train the model and the accuracy of the prediction drop. You should train your model on a more powerful computer and only load the trained model when needed.
It's still great to have the ability to run a machine learning model directly inside your browser, it makes your integration into your existing project easier.
In conclusion
TypeScript can now be used everywhere and make the development much smoother with only one programming language to learn. No more context switching between programming language and all the stack is unified.
If you are building a SaaS product and want this unified experience, you can try Next JS SaaS to start your TypeScript projects in seconds. We handle all the boring things for you like Auth, Payment, Landing Page, User Dashboard, form and error handling, database, CRUD operation, etc.
Top comments (36)
Learning other languages is also a good idea though. Every front-end web-dev should also have a look at languages like C or Rust to get a better understanding of how many things work under the hood.
It's also a very different way to go about coding that requires a somewhat different way of thinking and problem-solving.
Agreed, besides other languages in which are used along with Typescript, the language itself has some downsides and case scenarios in which it's not the ideal language to use.
dev.to/rammina/downsides-of-typesc...
Definitively, TypeScript has some downsides. But, once you take the time, TypeScript has a lot of advantages.
You have all the advantages from JavaScript with less negative ones.
Typescript does not have all the advantages from JavaScript.
Note: I am not personally attacking you, I mean well in the sense that I don't like misinformation.
Unfortunately, I can't agree with you in good faith. Here are my counterpoints:
JavaScript and TypeScript are not the same language. Typescript is a superset of JavaScript, and it is compiled to Javascript in the end.
It is an incorrect generalization to assume that all modern framework and libraries have type definition files. In fact, there are more modern libraries that do not have type definition files.
False claim. Would you please tell me why are these humans/developers complaining about how slow Typescript compiles?
This is coming from someone who loves Typescript by the way.
You haven't understood my responses... I have always put nuances in my responses and you have miss the important notion in my response.
Maybe my writing wasn't good enough or you miss what I trying to say.
No worries! :)
I will stand by my opinion, you can have yours, and so does everyone else.
We can just agree to disagree.
"..has few downside", so does every language!
We’re not writing our code in TypeScript, why? | by Erik Westra | Kaliber Interactive | Oct, 2021 | Medium
Erik Westra ・ ・
Medium
Without having properly read the article, I can add my reason for not using TS: I value the flexibility of an untyped language more than the added safety that a type system offers.
TypeScript has quite a flexible type system. However to express some more complicated types requires quite a lot of effort and knowledge.
Important things that I think are missing:
User) combined with actual usage (for example: the function expects something that has anameproperty). It would be great if any type system would combine this. Note that this is explained better here: youtube.com/watch?v=YR5WdGrpougI think you're attributing more features to a type system than it should actually have. When you start adding predicates like "having a
namefield" you're ending up back at set theory.Might be. I was thinking more along the lines of Nominal typing vs Structural typing and in a sense a mix between the two.
I still maintain that dogmatic type-safety is a crutch to solve structural problems more than anything. I have never once thought "Well, this wouldn't have happened if this had type declarations". Not in PHP, not in Python, not in JavaScript. I've very much thought "Why did this API suddenly change?" and "Where's the goddamn documentation for this?", though.
That's not to say there aren't any benefits to an opinionated, strongly-typed language (as TypeScript would like to be). When the language is built from the ground up with the ingrained opinion that it must prevent developer error at any cost (Golang is an excellent example of this), it does have some charm. Golang in particular goes a lot further than TypeScript, though, and ironically makes you feel a lot less dirty for using
interface{}than TypeScript does forany(or Java does for<? extends Object>:P )The drive to make every language type-safe obscures the real issues of language design. PHP's often confusing APIs randomly swapping argument order, Python's indifference to type inferrence, JavaScript's habit of thinking everything is a float under the hood... These issues aren't solved by making the languages type-safe. And neither does it really solve developer errors.
If anything, TypeScript in particular (due to compiling down to JS) can give you a false sense of security. Type defs are maintained often independently of the actual code mapping to them, and handling external data still runs the risk of runtime errors due to bad assumptions or changes in APIs (browsers maintaining dozens of different engine levels also wreaks some havoc at times).
Yep I totally agree with this. I use Ruby at work, Lua at home and JavaScript both at work and at home; and the types of errors I deal with are almost always related to much more complicated things than a value having the wrong type.
Having worked with languages like C and Pascal before, I'd even say it's the opposite: not having to type your variables is one less thing to keep in your head making a bit more room for the actual logic you're trying to translate into program code, so it helps with reducing bugs caused by dumb oversights.
Just as a small anecdote to underline this: The last bug I found today was that a function to calculate the length of some text was being called before the applications fonts had been fetched, so it used some default font of the browser instead and the result was off by a few pixels. No amount of typing could have fixed this, and in the end the problem was fixed by reasoning about what's happening. Those sorts of high-level problems are the ones I find myself solving most of the time, whereas type mismatches are usually a matter of reading an error message and saying "Oh, of course, this has to be a number"
Thank you so much for this article!
It's really informative, well-formatted, and I enjoyed reading it.
Overall TS brings some sanity to an insane language. Mostly helping to catching bugs before running being the primary benefit with the secondary being making it easier to reason about your interfaces, for example with
function foo(s: string, n: number): booleanyou know the expected arguments are a string and a number with the return type of boolean. All major IDEs leverage TS providing type hints.There are some disadvantages:
prop.onClick(id as number)@ts-ignorethere's a bigger problem than TS going on.I agree with your points. We have a lot of overlaps when it comes to opinions about its downsides.
Number 4 is so awful and relatable. Even a popular library like redux-form has really bad issues with Typescript, and people over at Github and SO are struggling to find stopgap solutions to errors.
I get it, you love Typescript, a lot of people love that language, and so do I.
However, your title is clickbait and it can be misleading for beginners. The article is nice and well-written, but I'm going to have to disagree with some points.
In any case, here are some scenarios and downsides of Typescript:
dev.to/rammina/downsides-of-typesc...
Oups, spotted, I'm huge fan of TypeScript... In this article, I was trying to hide my love to TypeScript 🤣
To be fair, in my article, you can replace every reference to TypeScript by JavaScript. It also works.
My point are that both languages are very versatile.
Sure, you really love Typescript. I know you mean well.
However, it does not change the fact that some of your points are misleading, and the fact remains that Typescript is definitely not the only language you need to learn.
I'm just saying this for the sake of beginners who walk into this thread/post.
I don't want them to start thinking that all they need to learn is Typescript, because that is not true at all.
A more appropriate title and introduction would be, "Typescript is a versatile language and I love it."
Sticking to one language is simply not possible that's all.
Each language has its own dedication. There are things you won't implement using javascript but rather Golang or Python ..
Some developers will argue HTML and CSS aren't a programming language 🤣 I think it definitively make sense to build webapplication and mobile application in one language for a small team with limited resource and time.
Python has huge advantage in Data Science and the community in this field seems much more larger. Golang are more targeted to low level but for high level application like web or mobile, TypeScript can be one of the solution 😃
Lol!
Don't get me wrong , I'm not a TS hater.
But one language for everything is such a bullshit , idiotic ideology & this works only for those fanboys who are averse to learn others stuff. Never fall in love with one solution for every problem , this is like using hammer for breaking an egg. Every project has different requirements and every problem requires different solution.
Same here, don't get me wrong, I'm not a multi-programming language hater.
I started programming in PHP on LAMP stack. Doing Java & React stack for full-stack application. Making some game in C#, doing machine learning and image processing in C++, reimplementing bash shell in C from scratch, etc...
And yes, every project has different requirements and context.
I didn't give enough of my context in my article. I'm indie maker with limited time and resource. I'm currently building high-level application as a solo developer. So, one language is appealing.
Sticking to a single language for everything is the second worst thing you could do (the first is using TypeScript as only language). Nowadays it's always "use JS for everythiiiiiiing!", so I get why you would say "use TS for everythiiiiiiiing", but actually you're making a silly mistake that's hurting your developer career - but you're most likely young and think that at 30 you're old and decrepit, so it's no point arguing with you. Your approach to programming is toxic, short sighted and naive, but you got the likes and the clicks I guess it's enough for you.
Keep spreading your message, more opportunities for us older folks who can use several languages according to the needs. Cheers!
Sorry, you've made some wrong assumption... I'm an older programmer (if you consider someone above 30).
I'm a multi language programmer: I started programming in PHP on LAMP stack. Doing Java & React stack for full-stack application. Making some game in C#, doing machine learning and image processing in C++, reimplementing bash shell in C from scratch, etc... the list goes on.
I won't argue more, whether my title has been misleading whether you didn't read the article. Cheers!
That's even more surprising, so either you've hopped on the fanboy train or you've forsaken all your experience and knowledge in favor of, what? Lazyness? Having used the "right" tools for a job - for several jobs, actually - do you really believe typescript to be a valid susbstitute, or you've just making a proof-of-concept? Would you really trade C# (or even an interpreted lua) in favour of TS for game development, for example?
Your article says you "might", your title says you "ought to", you're experience says "you shouldn't and you don't".
I'm gonna be real. I personally refuse to build a social network with a scripting language. I also gave up on PHP. I've moved on to converting all of my backend to Rust for the most part. It's amazing in the frontend, but that's my limit.
Typescript is awesome for bringing some sanity to the chaos that is javascript, but even if there was a single language suitable for everything (which there isn't), it wouldn't be typescript or any javascript-based language. And I can't be alone in preferring to set my servers on fire before I'd ever use any kind of javascript outside the front end of a web stack; it just isn't a language that holds up in the worlds of strongly typed precompiled languages.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.