How did you switch from JavaScript to TypeScript?

How did you switch from JavaScript to TypeScript? I really would love to hear how other people did it.

Why did you do it, what techniques or ways did you use to make it painless and smooth? 😁

I have used TypeScript several times however in React. I was preparing my portfolio for the job hunt and I thought I might need something more. I didn't enjoy it and then didn't use it anymore.

Recently I have seen TypeScript almost everywhere and while planning to hop back to the job hunt again (after trying to find my first job with 300 resumes sent), I decided to take TypeScript more seriously.

I see TypeScript in many job listings, in my country (Georgia), as well as in many European countries and America, not sure about Asia. Seems like I do need it.

So, I decided to start with Vanilla JavaScript, instead of React because I have been targeting Vanilla first to strengthen the fundamentals. Also, I can write code but sometimes have a hard time really explaining it theoretically and that's what I need for interviews.

First, I spent 2-3 days reading the official documentation and making notes about everything. Then I re-read these notes several times and somewhere at 80% of the documentation I got bored. I am that person who falls asleep when reading. I usually learn faster from practice so I prepared some theoretical knowledge and started converting my JavaScript to TypeScript.

It was horrible! I hardly could use whatever I learned from theory, I forgot everything I wrote down and read and I got stuck. My goal was to try to read, remember, and then try to use that in knowledge. Nope.

In the end, my plan didn't work, I just started learning while fixing all the red lines and googling here and there. The first Vanilla project (very small) took me almost a day to convert to TypeScript because I had to google a lot but also read why I was doing this. I also used ChatGPT a lot to increase the time spent on coding instead of googling and filtering information. Seems like writing 2023 doesn't work for search anymore.

On the next day, I continued doing the same but then realized most of my projects were on React. So I found random projects on Github and started converting them to TypeScript. And started to become better and better.

My main idea was not to code from scratch and try to come up with all possible case scenarios for TypeScript but instead take the projects already made with Vanilla JavaScript and convert them to TypeScript. And working on other people's projects also could be an additional plus because I learned to read other people's code.

Today is going to be my 3rd day of practice and I was trying to analyze whether it is working or not.

Surprisingly, the case scenarios never end. I learned how to create interfaces but didn't create aliases yet, not sure why haha. Then used a lot of type assertions to work with the DOM, optional parameters, and of course, generics. Getting stuck with asynchronous functions at times but I do feel like it did get better. I am thinking of continuing this way and then switching to React in a similar way.

So, how did you learn TypeScript? Maybe you plan to and you have some great ideas?

Comments

[JoelBonetR 🥇]

That seems to be the hot topic of the week lol

The question that you need to ask yourself is how much of TS do you want to use?
Because using OOP in frontend is generally inadvisable (tree shake works 100% on all paradigms but OOP 😅 reason being that dynamic access to properties and methods is really hard for static code analysers) so you probably won't be using certain OOP-related features in React Apps, specially with React 16.8 onwards.

Now you can have type hints without having TS as a dependency, see here:

To TS or not to TS, that is NOT the question. Is it?

JoelBonetR 🥇 ・ Apr 26 '22

#javascript #typescript #discuss #devjournal

VSCode will use TS behind the scenes to give you the DX stuff while you avoid the transpilation steps.

Now if you want to learn TS in depth there are plenty of courses out there.

That being said and as @artxe2 commented down below, there's a proposal to introduce type hints in the JS Core API, they look much like Python's or PHP's which is great if you ask me, and whenever this is released there would be no reason for using TS in most projects, hence rendering TS obsolete for thousands of people.

Even if you -whoever is reading this- are a TS tribe enthusiast, It's the natural lifecycle of any tooling; Whenever they get popular by solving a need, people ask for it, swapping the priorities on the core language maintainer's roadmap and eventually getting the good parts of that library re-thought and integrated along the core API of the language, then the library begins to fade.

This happened with jQuery: we got querySelector, querySelectorAll and a bunch of other neat features, nowadays jQuery is anecdotic and it's usage is legacy even in Wordpress to speak about one of the big ones.

Web Socket related libraries, which will probably be dropped as well whenever Node ships with native websocket support on version 20 -if I recall properly-

Happened on many other libs, frameworks etc and will eventually happen to TS.

TL;DR

TS is necessary in most projects as for now, this may change in the "near" future.
It's up to you to decide how many effort do you really want to put into it. If you just want type hints it can be learnt in like 10 to 30minutes, then try to do something using them and call it a day, it's a perfectly valid approach.

[Ekaterine Mitagvaria]

Well, that is a detailed explanation which definitely should make many re-think the goals.

To be honest, I feel like I am forcing myself into it because I see a huge demand for it from companies but I have not used it enough to really understand whether I personally need it or like it. I am not at the level to really judge it. I constantly see so many discussions around it but it's so complicated lol. I read your post, I will definitely try the second approach TS Pragma.

But if there will be such improvement that we don't need TS soon, I am more than up for it but if TS will help me with the job search right now I am ready to suffer 😁

[JoelBonetR 🥇]

See, by doing that step forward you'll try type hints on your own and make your own opinion!

Type hints are a great feature and most languages (compiled or not) implement them, JS is catching up at a different pace, as every language has it's own context and market niche (though everything that can be coded in JS will eventually be coded in JS 😂) hence it's own priorities (usually and ideally driven by the users but some times it's otherwise tbh).

I'd suggest you to create a project using TSPragma + JSDoc and then another one with TS alone, where you'll be able to choose whether you want to stick with type hints or take advantages of other TS features -if any works on your context- this way you'll be able to discern in which situations TS is still valuable when we finally get type hints in JS 😁

PS: looking forward to read new posts and see how this adventure goes!

Best wishes

[Ekaterine Mitagvaria]

Thanks for the suggestion, I will definitely try this!

[Eckehard]

Is there any evidence that "tree shake works 100% on all paradigms but OOP"? I´m building OOP frontends and there is absolutly no good reason this affects the ability to tree shake the code.

[JoelBonetR 🥇]

I was afraid of someone asking this after submitting the comment 😂😂

As I said it won't probably work 100% with OOP, reasons and examples down below and non-OOP examples for comparison.

What is Tree Shaking?

From mdn:

Tree shaking is a term commonly used within a JavaScript context to describe the removal of dead code.

It relies on the import and export statements to detect if code modules are exported and imported for use between JavaScript files.

In modern JavaScript applications, we use module bundlers (e.g., webpack or Rollup) to automatically remove dead code when bundling multiple JavaScript files into single files. This is important for preparing code that is production ready, for example with clean structures and minimal file size.

How

To safely omit code the bundler needs to be 100% sure that the discarded code is not being accessed anywhere in the bundle.

There are several ways in which this can be accomplished but 100% accurate escape analysis isn't feasible because the bundler would need to inspect every module in the graph in a way that's even more deep than most type checkers.

Little disclaimer

So I was writing everything on my smartphone's notepad when I stumped into this reddit discussion - This guy Manbeardo explained it pretty well so I'll just copy paste the comment and link the source, all credits on this examples to this guy Manbeardo.

Explanation and examples

In order to safely omit code, the bundler needs to be certain that the omitted code isn't accessed anywhere in the bundle. There are several ways that can be done, but maximally accurate escape analysis isn't feasible because the bundler would need to inspect every module in the graph in way that's more comprehensive than most type checkers.

Here's a bunch of examples of code where methodB can safely be omitted, but with different levels of analysis required:

ES6 module shaking:

// BagOfMethods.ts

export function methodA() { ... }
export function methodB() { ... }

​// entryPoint.ts
import {methodA} from 'BagOfMethods';

methodA();

In this case, it's very evident to the bundler that methodB can be omitted because it's never even imported.

Destructuring assignment using commonjs:

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const {methodA} = require('BagOfMethods');

methodA();

In this case, the bundler can still determine safety solely by looking at statements where BagOfMethods is imported, but it requires slightly more sophisticated analysis.

Dynamic access plausible:

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');

BagOfMethods.methodA();

In this trivial example, it's pretty clear that methodB isn't going to be called, but it's possible to access methodB on a subsequent line, so we have to process the rest of the module in order to find that BagOfMethods never escapes this module and this module never calls methodB. Things get hairy when BagOfMethods escapes in the next example.

Indirect dynamic access plausible

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// BagUser.ts

type Bag = {
  methodA: () => void
};

class BagUser {
  constructor(bag: Bag) {
    bag.methodA();
  }
}

module.exports = BagUser;

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');
const BagUser = require('BagUser');

new BagUser(BagOfMethods);

Now, in order to determine that methodB isn't called, we'd have to either:

• Potentially traverse the entire module graph every time we evaluate a module for potential omissions
• Store a lot of metadata about what every module does

We're getting into the realm where the bundler needs to do as much or more analysis than the TypeScript type checker. If you're aware of a bundler that's built from the ground up to support TypeScript, I'd be excited to hear about it.

Dynamic access

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
  methodC() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');

function pickMethod() {
  if (Math.random() > 0.5) {
    return 'methodA';
  } else {
    return 'methodC';
  }
}

BagOfMethods[pickMethod()]();

We don't have to expand the graph in this case, but we're getting deep into typechecking weeds again before we can determine that methodB isn't called.

And the potential complications go on. As an engineer looking at code, it's labor-intensive and error-prone but plausible to manually identify methods that can safely be omitted. For webpack to catch all those cases, it'd need a type inference engine that's at least as powerful as TypeScript's.

Dynamic?

Now it's me, Joel again. While the examples above cover a great deal of bits around the topic, I'm adding a quick example after re-reading them twice.

import myClass from 'myFile';

myClass[variable]();

If you do so it won't be possible to tree shake it, because it's using a static analyzer behind the scenes so any method described by variable is possible at runtime.

When using functions it's quite easy:

import { myFunction } from 'myFile';

// here we'll have acess to myFunction but nothing else

Remember that in JavaScript, like in other languages like Python, everything's an Object, extending the example above you could do:

const myObject = {
  myFunction: (n, n2) => n+n2,
  myProperty: 'I am a prop',
  anotherFunction: () => 'that returns a text'
}

and it's perfectly fine, now if you access the properties it's ok for the static analyzer but if you do something like myObject[variable] it won't be tree shaked either.

With that in mind, it's safe to say that code that's purely procedural or functional won't be much of a trouble for the static analyzer whereas certain OOP edges and whatnot can be hard to deal with (just in case this is agnostic to declarative vs imperative or expressions vs statements -whatever you like to call it- that are often defined as paradigms as well).

wrap up

Last but not least, I'd suggest you to check your bundler capabilities and configurations in regards of tree shaking.

Certain use-cases exemplified in this comment are possible to overcome when tree shaking and are described here for educational purposes (so we all understand the challenges and limitations) specially if you avoid certain practices.

Please note that the websites of bundlers often explain what the tool does -in a vague way to be honest- but not what it doesn't, so some statements may already be solved since the last -and only- time I had to deal with this in deep detail.
For that, if you find something that can update my knowledge on the topic I'd be grateful if you share it 💖.

The limits on tree shaking your code will depend on:

• Your code itself.
• The capabilities of the bundler.
• The configuration that's available to you.
• Your will to maintain the configurations during the development process

In regards of the last point, sometimes the benefits of not having to care are greater than the benefits of saving a couple of kb in your bundle 😅

All that covered, whether you use -or should use- OOP or not depending on the situation is a totally different discussion.
I consider FP to be much more understandable and maintainable -even though I don't always use FP myself- but that's my subjective opinion based solely on my experience.

If you ask me, code in the paradigm you feel more comfortable with, being multi-paradigm is one of the most important reasons to love JS IMHO.

Best regards 😁

PS: This comment could be a post lol

[Eckehard]

Ok, you want a simple world for simple peope, that´s pretty ok and often enough necessary. And Yes, it is generally not advisable to use any paradigm that you do not understand or do not like. But this does not make OOP in general unusable for frontend design.

With regard to tree shaking, there are some general pattern you should avoid. But most of them have nothing to do with OOP, they apply to functional or procedural libraries as well. We did a lot of tests with VITE / Rollup, and as long as you do not build "God-classes", OOP libraries perform not much different than other libraries. The worst thing you can do is to build a single class that implements all the functionallity like REACT does. See Why is my React component library not tree-shakable?.

So, I would say: The only thing that is not advisable is, to oversimplify things!

[JoelBonetR 🥇]

So I read the SO entry entirely and there's nothing that points to "React implements all the functionality in a single class" and even if it would, thats not the point.
The OP on that issue had this dramas:

The Icon component imported all icons so that all svg files ended up in the bundle as soon as you used at least one icon or a component that uses an icon.

The Theme component inlined a font as a base-64 string into the bundle.

Which have nothing to do with React, you'd get the same result with Vanilla JS or any framework/lib.
On the other hand, it solved that by splitting the bundle into chunks, a practice that's been business as usual for the last years (the post is near 4 years old) and dynamic imports (introduced in ES2020).

It's not a simple topic by any means, static code analysis is easy in simple examples but can become hairy and tricky real quick. For that, different bundlers have implemented different -and most of the time convergent- features and with them, we're a step closer to "the perfect bundle".

Please, note that using few very big classes, or "God classes" doesn't make a difference at all in this topic, we split our files for DX and maintainability, the computer just don't care.

Of course, with a single class you'll loose the direct import/export analysis that would remove entire classes from the bundle if you split them in different files but it's the specific bundling of methods in chunks what we are talking about (plus in a situation of having a single class, spotting and deleting unused stuff would be rather easy for any developer).

Each bundler applied different approaches for users to interact with them "is it a configuration flag? A configuration object? Does it work automatically?...". By using these features one might get better results, and depending on your particular App, one bundler with a specific config may be better than any other alternatives (the hard stuff is checking that's still true every now and then during the development or maintenance process and maintaining the config up to date).

One might come and say that our information and understanding of this topic is rather limited or at least a bit outdated and it will be true. Honestly I don't have time in my roadmap to revisit this topic for the near future, I'm loving this little deep dives, tho

[Eckehard]

What has the Icon component to do with OOP? Nothing! You are describing the general problems of tree shaking.

Because using OOP in frontend is generally inadvisable (tree shake works 100% on all paradigms but OOP

It is fully ok that you have your personal preferences, but this kind of OOP-bashing is not helpful.

[JoelBonetR 🥇]

This is a different issue not related with any paradigm in particular and is on the bundlers rooftop. Luckily it's solved since ES2020 with dynamic imports and bundlers "recent" features.

On the other hand, I meant it strictly. If you use pure functions or imperative declarations you won't find this kind of issues, whereas toying around with classes and objects you might.

E.g.

// class instance method dynamic access
const service = new Service();
// Static analyzer can't be sure what service method will be invoked
service[kind]();

// imperative
if (kind === 'a') {
  // do this
} else if (kind === 'b') {
  // do that
}

// FP
function exists(value) {
    return function (func) {
        if (value !== undefined) {
            return func(value);
        }
        return null;
    }
}

const doThis = (val) => console.log('doing this', val);

exists('a')(doThis); // doing this a
exists()(doThis); // null

The first example can also be accomplished by using interfaces, maps, overrides...

Of course if we talk about JavaScript, a multi-paradigm language you have a wide range of solutions that use bits and pieces of every paradigm. A couple of examples:

const myClassInstance = {
  exists: function(value) {
    return value ? this.doA() : this.doB()
  },
  doThis: function() {
    console.log("A")
  },
  doThat: function() {
    console.log("B")
  }
}

myInstance.exists( variable );

const myInstance = new MyInstance();

function callOneOrTheOther(condition) {
  condition ? myInstance.doThis() : myInstance.doThat();
}

const myClassInstance = {
  doThis: function() {
    console.log("A")
  },
  doThat: function() {
    console.log("B")
  }
}

if (value === 'a') myClassInstance.doThis();
else if (value === 'b') myClassInstance.doThat(); 

It's not that I advocate for not using OOP, just in case you got that impression. I recommend to use the paradigm that best suits every little piece on your software solution because that's the beauty of multi-paradigm languages! And of course, that includes OOP as well.

This wide variety of workarounds to define an algorithm is what makes this topic so difficult, not just for static code analyzers but also for the JIT Compiler, garbage collectors and so on and so forth. Now based on my limited experience and knowledge, OOP is a bit more tricky to overcome, generally speaking.

I personally write code in both backend and frontend, and I use all paradigms whenever necessary of course!
Oftentimes I got the feeling that "a more strict OOP approach" is more suitable for backend than it is for frontend, at least certain features or workarounds for the reasons explained above.
I truly believe you could accomplish everything with OOP by using other paradigm features whenever necessary and if you're very picky designing your software, though is something I don't want to put that much effort into honestly, as it looks like premature optimization to me 😅 so I usually pick the opposite approach on client side and it's what I would recommend if you ask me.

[Eckehard]

This should definitely be a different post....

The approach to use depends much on the task you have. It is a different game if you need to serve a solution for Amazon, or if you set up a private homepage.

We currently see a shift to build web applications that contain more than just the frontend logic. I´m even not sure if we should call this apps "frontend apps", as they contain both, frontend and "backend"-logic. This is not a solution for everything, but an interesting approach for some tasks.

As things run on the client, you would not use this "huge" libraries we all know from traditional application development. If the classes are not too big, we see that tree shaking performs well, even with a class based approach. It is not a perfect solution and you can easily make some faults that prevent the whole lib from being reduced, but this happens on the library and can easily be optimized. Using these lib´s usually does not cause issues.

So, the web continues to develop dynamically, and we should keep our eyes open to different solutions.

[JoelBonetR 🥇]

Definitely, and sometimes is exhausting isn't it? 😅

[Adam]

What does OOP have to do with Typescript?

[JoelBonetR 🥇]

TS adds some OOP stuff that's not available in JS core API, one example of these could be interfaces.

[Adam]

interfaces in TS have nothing to do with OOP. Interfaces (and types) can be used (and are, because it's how I use them) to describe plain JavaScript objects, and 98% of the code I write is functional.

Type hints may one day very well be built into existing ECMAScript engines like chakra, v8, etc. If they are, then they'll probably take a very similar form of TS current annotations. Even the proposal you mention surfaces the limits of JSDoc type annotations.

The argument against TS because of transpilation - it changes "my code" - is a weak one because transpilation is so deeply ingrained (currently) in the JS ecosystem/toolchains. It'd be nice if transpilation wasn't in the future, but for the time being, because I'm transpiling everything else I might as well add TS to get some compile time safety/ease of cognitive burden.

So, in the future, when the ECMAScript spec (and the implementing engines) implement type hints natively, thank goodness we won't have to use TS anymore because, at that point, JavaScript will effectively be what TS is today. TS can easily be viewed to have been created as a stop gap until the ECMAscript spec could formally adopt type annotations into it's spec - just like jQuery was a very useful stop gap until browser vendors got their crap together.

And, because TS is a superset of JS, I can drop a loose tsconfig file into my vanilla JS project, compile it and call it TS - my point here being that you can adopt "type hinting" incrementally in any project (this is me pre-empting a potential counter-argument).

Your comment (specifically the part about relating TS to OOP) makes it very clear than you're trying to overstate your knowledge in the area. It's a shame dev.to (and the programming articles on medium too lately, I've noticed) have devolved into such click-bait flame ware nonsense.

[JoelBonetR 🥇]

I agree with some things you said here and I am perfectly aware that you can use interfaces to describe types in TS.

Now you're the first and only person I "faced" who stated that interfaces have nothing to do with OOP 😅

I want to believe that in the Java world everyone's aware that lambda expressions are a feature from FP, the same way and till today I believed that everyone was aware that interfaces are a feature from OOP. Apparently I was wrong.

interfaces are essentially a means of describing the shapes of X, where X is usually a Class but in JS everything's an Object, so you can also describe the shapes of your objects when using Interfaces (predicting the reply, Functions are also objects, arrays are also objects, classes are also objects...).

Last, TS have to do with OOP in the sense that it implements interfaces -nowadays that's pretty much the key difference-, now If you look back in time, before we got most OOP features in the JS core API they were implemented by TS, like private class fields just to add another example and of course TS supported the class keyword and class-related features before we even got ES6 to add them natively.

I know that the class keyword and related features in JS are just syntactical sugar over prototypal inheritance but man, the simplicity feels good don't you think?

[Adam]

I meant that the interfaces in typescript have nothing to do with OOP. Typescript is not Java. Java is never functional (even despite some of the latest efforts) - the language (Java) itself dictates the programming style.

TS (just like JS) can be written equally in a functional way or an OOP way (I nearly always use the former).

Choosing to use TS over JS doesn’t mean you’re going to be writing your code in any different way at all, except now you’ve got type-safety, to your own preference (you can still use any or compile without any annotations), and compilation step.

This is why your original comment made no sense to use the term OOP - TS has nothing to do with OOP. At all. I don’t know why you included the term.

[JoelBonetR 🥇]

I honestly can't remember why I talked about OOP at the beginning, sometimes I get influenced by other posts I'm reading 😂😂 sorry for not being able to satisfy your curiosity... 😅

Now that we are here, and as the post is about learning TS I would like to extend that a bit more for the readers that may land here. I'll also explain why interfaces are related to OOP also in TS if you are curious.

---

In software development, an interface is a concept applied in Object Oriented Languages (or languages that implement OOP even if they are multi-paradigm), you can read more details here.

Consider the following scenario in TypeScript using interfaces with the extends keyword:

interface Animal {
  size: number,
  age: number,
  scientificName: string,
}

interface Dog extends Animal {
   bark: Function
}

By declaring the Dog interface with extends we are applying OOP inheritance.

That means that Dog implements everything that's in Animal plus specific Dog stuff, Dog is inheriting from Animal.

This will work with both classes and plain objects of course!

// if you remove one of the properties that come from Animal or the specific Dog one you'll get an error
const myDog: Dog = {
  size: 55,
  age: 8,
  scientificName: 'Canis lupus familiaris',
  bark: () => 'Woof!'
}

Now, if you are not using extends most of your interfaces are probably replaceable by types
Type Hinting is a language feature, not related with any paradigm in particular.

Should you do so? Well, not necessarily. Types and Interfaces in TS are much similar one to another.

My rule is to use type aliases by default and interfaces whenever necessary (edgy cases), but you might well do the opposite and it will work.

My reason for it is the simplicity, I use FP most of the time for the same reason, I prefer code to be as simple as possible (KISS software design principle).

Consider the following scenario:

type RGB = `rgb(${number}, ${number}, ${number})`;
type RGBA = `rgba(${number}, ${number}, ${number}, ${number})`;
type HEX = `#${string}`;

type Color = RGB | RGBA | HEX;

const backgroundColor: Color = `rgba(25, 25, 29, .9)`;
const textColor: Color = 'rgb(250, 250, 250)';
const borderColor: Color = '#fec590';

You may find it to be a lot more complicated if you try to accomplish the same with interfaces (I invite you to try it, as an exercise).

Best regards

PD: BTW sorry @catherineisonline for the long discussions in your post 😅

[Ekaterine Mitagvaria]

No worries! It's a lot of new information for me and I will definitely lurk around your discussion 😁

[Rense Bakker]

You can use typescript only for type hints as well... Just add strict:false to your tsconfig 😛

[sargentogato]

I heard something totally different. TS it is no necessary, could be good for some things, but if in the future you have to move to another framework or whatever, having TS could be a problem, as well it is introducing another layer of complexity. What I heard was, JavaScript it is much better option, cause TS can upgrade and loose backwards compatibility.

[Rense Bakker]

Actually typescript is widely known for NOT losing backwards compatibility or any breaking changes in the first place...

[JoelBonetR 🥇]

True.
And in case ES adds support for types on a similar or exact manner than TS does, you're working with a .ts file and the bundler takes care of it anyway, meaning that the output will be without types as type hints are mainly useful in dev time, runtime errors should be handled programmatically for good.

[Peter Vivo]

My journey began with ActionScript, transitioned to JavaScript, and eventually led me to TypeScript. Before Flash's decline, I began transferring my expertise to JavaScript. At that time, ActionScript boasted slightly superior OOP capabilities. I continued working with JS, React, and functional programming rather than OOP until 2021.

In 2021, I undertook the task of converting our React/JS project to a TypeScript solution. For mission-critical parts, I introduced type declarations. This approach not only worked efficiently but also provided significant assistance during development.

This year, I transformed my React/JS npm module, react-troll, into a React/TS module: react-state-factory. Although simpler, the latter proves to be far more useful.

[Ekaterine Mitagvaria]

Thanks for sharing your story! You have gone through a lot 😁

[eshimischi]

I work for a large company, but none of my colleagues use it. I just single-handedly began to start projects of small internal libraries that are used in our projects, written from scratch in TS, at first there was a simple tabs library, now a more serious dashboard project in Vue3+TS. In order to at least somehow move towards development, I took upon myself the responsibility to start writing on TS, thereby bringing my colleagues to the idea of what needs to be done. TS is no more a trendy thing - it is what the modern DEV world look like, we can't ignore the fact that this tool is useful and also rises the level of JS understanding too.

[Ekaterine Mitagvaria]

Thanks for sharing! Do you enjoy using TypeScript?

[eshimischi]

Love it. At very first i was struggling with it, but now i do understand what am i doing and what for, devtut.github.io/typescript/gettin...

[Ekaterine Mitagvaria]

That's great! I am a little getting used to it already 😁

[eshimischi]

Can't imagine life without it already lol. All the greatest repos on Github are already TS-only, so we have no choice but to learn typescript

[eboye]

I was forced to by the team I joined. I never wanted to use it. I think it's the Microsoft's another attack on open source and web which is just not as they would like it. The roots go far into past where they post battle with Netscape and it's JavaScript which was not what they intended.

[Ekaterine Mitagvaria]

Seems like you don't like it much either 😁 Did it take you long to switch?

[eboye]

Well,

it took me 4-6 months to get things going, but I'm still making mistakes and finding myself spending time fixing typechecks where I'm 100% sure it would pass. But any is not an option in our project so I have to hunt down how to transform, extend etc. to make it pass the checks.

[Ekaterine Mitagvaria]

There definitely can be many tricky moments

[Rajae Robinson]

Great post, as a coincidence I recently wrote an article on migrating a project from JS to TS. As you mentioned, starting small and fixing the errors as you go along might be the most feasible approach.

I was in a similar situation where I worked on a React project that transitioned to Typescript. I had no knowledge of it then, but I was able to learn quickly through trial and error and leveraging my existing knowledge of other strongly typed languages such as Java and C++.

[Ekaterine Mitagvaria]

Thanks for sharing! Having such a background definitely helps a lot which I don't have yet, unfortunately.

[Etienne Burdet]

It's much easier to learn by coding new stuff straight into TS, than converting old code. When migrating old code, you always have to ponder wether you have to find a way to please TS or if your code really has problems, which is hard at first (and TS is very, very often right).

When writing new code, force yourself to type straight from the beginning. A bit as form of TDD: write down what you think should be in, what should be out and then find a way to match that. Refine, iterate…

Avoid having any everywhere and type more strictly at the end. This is the way TS will just be a pain.

[Ekaterine Mitagvaria]

Yes, I am not using "any" anywhere at all and trying to avoid it at all costs, otherwise makes no sense anymore.

For some reason, I found that approach would take longer and it would be harder to come up with all possible scenarios but maybe I should try that as well so I can compare.

[JorensM]

My first programming languages were strongly typed languages - C++ and Java. While learning them I really disliked the 'strongly typed' aspect of them, and all the time wished that there was a way to declare and use variables without needing to specify their types. Then some years later, a savior came from above - JS. I was mindblown by the fact that you could create variables and functions without needing to specify their types. As I started learning and working with JS more and more, I noticed that a lot of errors began occuring related to incorrect types etc. So I realized that a dynamically typed language, although oftentimes useful, can also be a crutch. Then I discovered TypeScript and have since gained appreciation for typed languages and now use TS for all my projects. So I guess I went full circle. Working with JS and then TS allowed me to understand that type safety can be a real life saver and will prevent you from making many tiny silly mistakes that would take a while time to debug otherwise.

So lesson to take from this - be careful what you wish for!

[Ekaterine Mitagvaria]

Thanks for sharing your story, I never really thought about the experience from the other side when someone switched from strongly typed language to JS 😁 I didn't get the chance to fully understand if I like TS yet but while learning, I actually realized how many checks I needed to avoid possible errors and never really noticed before.

[Juanda Martínez]

I'm also starting with Typescript, usually, I like to "rush" free Youtube courses or even buy some in Udemy on sale, I have the same problem that I get bored and even fall asleep just by reading tons of documentation or watching courses as well, that's the reason I watch the courses in 2x or a speed I can still understand the words in a fast way, then switching between coding stuff from scratch or grabbing come project and modify the new stuff I learn, the thing is that it was easier to learn Typescript for me because my first programming language was Java, I worked with it about a year when I was in college, so Typescript is adapting somehow the syntax to match the traditional POO paradigm and I just had to remember those concepts that I learned years ago, and that helped me a lot.

[Ekaterine Mitagvaria]

Haha, I also like watching videos on 2x a lot. It's probably much easier when you have a background in strongly typed languages.

[Sean]

Against popular opinion, I actually prefer typescript. To be honest. I'm not entirely sure why as it is definitely not as flexible as JavaScript but is more structured. I have read alot of JavaScript in my career and the s*** I've seen is unbelievable

[Jukka-Pekka Keisala]

I don't think your opinion is against popular opinion. TypeScript is great. This anti-ts drama roots to DHH's post about them not using TS on Turbo. But DHH has always been writing controversial opinions about what is trending. Probably next week he will tell DevOps is useless and we all should just use FTP.

[Ekaterine Mitagvaria]

Nothing bad about that! I also have seen a lot of people loving TypeScript. Personally, I am not sure yet. 😁

[Maria Zaitseva]

I tried Deno one day. It ships with a Typescript support out-of-the-box, so I was like "now I gotta try Typescript as well". And so I did. Another tool with (limited) built-in Typescript support is Esbuild — it's very good for small frontend projects, that's what I mostly use for my projects.

[Ekaterine Mitagvaria]

I will check this out, thanks for sharing your experience.