DEV Community

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

 
joelbonetr profile image
JoelBonetR 🥇

That's the key point. Using TS on a way or another 😆

Thread Thread
 
brense profile image
Rense Bakker

No, your way is a work-around to not use actual TS, but JSDoc with ts-check instead, which is not the same thing (which we've already established), you need to learn how to write proper JSDoc and you cannot use some convenience features that TS has, like generic types or type intersection features.

Thankfully, atleast you agree that type safety is important. You're convinced your way is better and you dismiss any arguments in favor of using just TS (which is nothing more than vanilla JS + type safety) it does not look like we're ever going to resolve that.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

Gosh are you like a fanboy or something?
Each project has it's needs. There are tones of JS projects, is the most used programming language in the entire planet. TypeScript was released in 2012, it's been almost 10 years by now, but do you really know it's market share?

If you're about to create a npm package you probably will add TS or d.ts at least to bring extra-compatibility, that's a thing.

On the other hand, I'm gonna show you a real life metric:
Job offers naming JavaScript in the European Union (remote filter On):
Javscript job offers in the EU
Job offers naming TypeScript in the European Union (remote filter On):
typescript job offers in the EU

That's a huuuge difference of 43.275 (~5.5 times more in favor of JS).

Let's look at United States (remote filter On):
Javascript job offers in EEUU
typescript job offers in EEUU

The diference is even bigger here, 153.011 (~7 times more in favor of JS).

Even that, you are suggesting learners to learn TS without learning JS first and stupid things like that.

What will you say? that companies using TS don't use LinkedIn? 😆 They suddenly hate microsoft so they decided to not using it's platform but keep working with TS? C'mon.

Do you really think that all those companies will suddenly migrate to TS for any reason? Are you that kind of utopic people that tries to change the world while refusing to learn how it actually works?

I can in fact get type intersection with this workaround and I do not need generic types most of the time or in 99% of my projects (either be personal or professional). Again, if you want this features, add TS and go ahead.

There are tones of posts telling people how good TS is since it has been released, still the amount of projects using it is low in comparison with projects that are not using it.

If I reach 3k people, they share this and they begin documenting their code and using some few features like type-checking in dev time, Welcome! We'll probably face better projects in a future.

Having people to know this one, the one that @patoi suggested or any other intermediate option is firstly a fact -because they exists- and secondly can be convenient for many.

It's ok if you don't share this feeling or preference but at least you can make the effort to understand it.

Thread Thread
 
brense profile image
Rense Bakker

Again, Typescript is a superset of Javascript. If you know Typescript, you can also apply for Javascript positions and nothing bad will happen. Except you'll have to deal with more runtime errors in production, which more and more companies are realizing is bad and costs them money.

You want to use your own method of preventing runtime errors thats fine I have very strong doubts that it is as effective as you say it is in a large software team (see all previous arguments that you chose to ignore). Unfortunately (or luckily) I have not encountered any large teams that used your method, so I cannot disprove your claims with hard numbers. Most teams I've worked in are comprised of humans who are sometimes lazy and make mistakes, which is why we chose not to rely on doc blocks for type safety.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

I you really want to know how it works, how it uses TS and so I can nicely explain more details. Some of them I already know others I may need to do extra-research.

I'm used to work with little teams (4 to 5 in frontend, 4 to 5 in backend, a couple in Data, infrastructure...).
We used TS in the project I was working on before and we have this approach on the current project. I've the role of tech lead/lead dev and I waited 8 months before posting this.
This post would have happened anyway but with two possible conclusions:
1- That's awful, let's migrate to TS and run.
2- That's actually nice, it covers the project needs.

And happened that was the 2 and here we are.

Another issue nowadays is the high demand of developers due to a low offer, and believe it or not, the amount of people that can code fluently with JS is notably bigger than the people that can do the same with TS.

The lack-of-devs issue in backend is also worrying, probably more than in frontend but still I feel that one of the benefits of microservices is not being addressed by the companies: Using different programming languages depending on the service.

I myself offered to code the gateway in Node JS but they prefer to keep all the backend in Java Spring. Now we need another Java Spring dev and finding one is lasting more than what I would like 😅

Thread Thread
 
brense profile image
Rense Bakker

"Another issue nowadays is the high demand of developers due to a low offer, and believe it or not, the amount of people that can code fluently with JS is notably bigger than the people that can do the same with TS."

Thats factually impossible though. If you can write fluent Javascript you can write Typescript (again, Typescript is a superset of Javascript). Javascript code is valid Typescript code (atleast before type checking).

You are right though, there is a lack of people with Typescript experience, however, there's an even bigger lack of devs who know JSDoc. So if it was your goal to cater to a larger pool of experienced devs, you failed (do that thing again on linkedin where you search for job offers, but this time with JSDoc 😂)

When companies cannot get on board with new technologies, even though they have a lack of devs who can maintain or build their Java crap app (Spring), thats usually when I end my contract with that company.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

Empirically tested it and it's not so easy to get people used to JS to use TS, it's learning curve is higher.
With JSDoc it was like "Oh it works like that, pretty straightforward, Ok".

By the way... why a Java Spring App should be crap? Don't you consider Spring as valid tech nowadays? I'm curious about that point

Thread Thread
 
brense profile image
Rense Bakker • Edited

Valid tech... what is your definition of valid tech? I did not enjoy working with Spring Framework at all. Granted it was probably less bad than "vanilla" Java. It's been a long time since I touched anything related to Java though, maybe it got better? I doubt it though...

Empirically tested it and it's not so easy to get people used to JS to use TS, it's learning curve is higher.

Thats not my experience at all. But it probably depends on how you introduce Typescript, if you false tell people that it's a completely new language that they have to learn I'm sure it will look daunting going through all the Typescript feature docs that you don't need as a beginner. It becomes a lot easier when you explain to people that their Javascript is essentially already valid Typescript code.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

There are people in the company that has been explicitly hired to teach and it's the first stage whenever someone wants to learn something new. I bet they do it better than I do.