Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
This is an opinion, not a definition. Assuming that TS improve the software quality we can extrapolate that and say that Java (which includes the "strong sides" of TS by default) improve software quality and by extension all Java code has quality.
I worked 4 years using Java and I'm confident to say that this is not true.
Strong typing and so gives your code robustness which is absolutelly not the same than quality.
SOLID principles, design patterns (when they fit), documentation, testing, good naming conventions etc are things that improve software quality and some of them also add robustness.
Moreover TS shines when dealing with complex logic (as it adds robustness, either be with ts-check pragma or adding TS into your project) and you are not supposed to add complex logic in the frontent (it adds coupling and makes hard to migrate to a new frontend technology when react dies in a future) so I would rather say "specially in complex Node services" instead "specially in React", where you will get interaction logic only.
I'm just going to ignore the absurd comparison with Java (The way in which Typescript deals with type safety is completely different from Java) and only reply to the more sensible part of your reply. SOLID is great, especially the parts that carry over to functional programming, yes design patterns, documentation, testing, good naming conventions, completely agree and there is zero reason why you cant do this in Typescript. The second part of your reply... Thats not the point of Typescript, the point of Typescript is that I can trust that when a team member writes some code or some intern writes some code and after a while I have to make changes to that code, I'm not confronted with a big mess of different styles of coding and variable declarations that are changed all over the place, holding values that I cannot predict. Typescript has made my life a lot easier and less filled with fixing nonsense bugs and typos. If you want to dismiss that as a personal opinion, go right ahead lol
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I know that difference between Java and TS, but making the assumption that TS always deals to a quality code is absurd in the same way.
I agree with you in most parts to be honest, it's just that, to add objectivity into the equation, you can get the same with JSDoc definitions and using ts-check pragma instead loading the entire TS as project dependency.
Again, I don't mean to say that using TS is bad or any other thing, it's just that fanboying a tech makes you think that it's good for everyone in every situation and for each use-case that you have to face and that's simply not true.
To get the correct tech stack for a project you need to check different metrics; the specific use-case/s to cover, the future planning, the human resources available (quantity, seniority, previous experience), the overall experience of the team on each tech stack and so on.
Then, in a perfect world, all projects would have unit tests, e2e tests, good documentation, an up-to-date confluence with the acceptance criteria to review before refactoring something and a huge etc of things.
The real life for most projects is that business needs go first and it usually means "We need this done by [DEADLINE]" which leads inevitably to cut time in some of those things, so you need to choose.
Do you prefer extended dev time by using TS? Do you prefer to have unit tests? Do you enforce documentation?
There are different approaches that lead you to -almost- the same result, for example, if you take the approach of "everything is a component" in React, using propTypes is more flexible than strong typing your code, plus you add explicit definition of what is optional and what is required and so on, just to add an incomplete example.
It's not all black or white, it's not a "good practice", it's not a use TS or not use TS, it's a tech stack definition and it will be the correct one or not depending on those different metrics I add before and it may be a question on "how much TS do you want to imply in your project" and for which reason.
I'm adding 2 use cases from some months ago just to illustrate.
Real-time chat app with Node + React using Websockets
and persisting data in a MySQL database.
It was meant to be integrated inside a different webapp as stand-alone webapp.
React code is just an entry point to authenticate the user in context + the chat component (divided in two, the place where you type and the place where you read). Around 200 lines of code as much, you just deal with strings.
Node backend it's just the event emmiter, the persister (to store) and the reader (to get previous chat history), around 150 lines of code as much if you put the files together, again you just deal with strings.
There is no logical benefit of adding TS. You can fantasize with things like "if the project grows then...", "if bla bla... then" but the reallity is that this project will remain as is for it's entire life.
Service to handle bussiness logic
Between a React frontend and a headless CMS.
Forecast of project minimum support time? 5 Years.
Forecast for project growth? Big.
Does this use-case fit for TS in the Node service? Sure it does! I wouldn't recommend doing it without TS.
Does this use-case needs to have TS in the React part (y/n)? No, it does not.
Are we about to using TS here? Let's see the rest of the metrics, oh, the team got experience with JS but few in TS, we are about to add only interaction logic to the frontend so we can cover the robustness with JSDoc, TS-pragma and prop-types.
That's the objective truth about this regarding the metrics, but you seem like the one dev that cries at the back saying "but we HAVE TO use TS" (usually just because he's used to it and as a personal preference) and can't give any good reason for it to Architecture and Management people.
I don't know man, jsdocs, proptypes.. I see that too often as wishful thinking, because only one dogmatic guy of the entire team is keeping those up to date and consistent. Strict ts is more friendly for a mixed-level team because it puts less burden on Sr engineers during code review to always double check if "best practices" are adhered to (and reduces friction due to being code-blocked during the code feedback stage)
A codebase with outdated jsdoc/proptypes/etc brings a tear to my eye.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
This is an opinion, not a definition. Assuming that TS improve the software quality we can extrapolate that and say that Java (which includes the "strong sides" of TS by default) improve software quality and by extension all Java code has quality.
I worked 4 years using Java and I'm confident to say that this is not true.
Strong typing and so gives your code robustness which is absolutelly not the same than quality.
SOLID principles, design patterns (when they fit), documentation, testing, good naming conventions etc are things that improve software quality and some of them also add robustness.
Moreover TS shines when dealing with complex logic (as it adds robustness, either be with ts-check pragma or adding TS into your project) and you are not supposed to add complex logic in the frontent (it adds coupling and makes hard to migrate to a new frontend technology when react dies in a future) so I would rather say "specially in complex Node services" instead "specially in React", where you will get interaction logic only.
I'm just going to ignore the absurd comparison with Java (The way in which Typescript deals with type safety is completely different from Java) and only reply to the more sensible part of your reply. SOLID is great, especially the parts that carry over to functional programming, yes design patterns, documentation, testing, good naming conventions, completely agree and there is zero reason why you cant do this in Typescript. The second part of your reply... Thats not the point of Typescript, the point of Typescript is that I can trust that when a team member writes some code or some intern writes some code and after a while I have to make changes to that code, I'm not confronted with a big mess of different styles of coding and variable declarations that are changed all over the place, holding values that I cannot predict. Typescript has made my life a lot easier and less filled with fixing nonsense bugs and typos. If you want to dismiss that as a personal opinion, go right ahead lol
I know that difference between Java and TS, but making the assumption that TS always deals to a quality code is absurd in the same way.
I agree with you in most parts to be honest, it's just that, to add objectivity into the equation, you can get the same with JSDoc definitions and using ts-check pragma instead loading the entire TS as project dependency.
Again, I don't mean to say that using TS is bad or any other thing, it's just that fanboying a tech makes you think that it's good for everyone in every situation and for each use-case that you have to face and that's simply not true.
To get the correct tech stack for a project you need to check different metrics; the specific use-case/s to cover, the future planning, the human resources available (quantity, seniority, previous experience), the overall experience of the team on each tech stack and so on.
Then, in a perfect world, all projects would have unit tests, e2e tests, good documentation, an up-to-date confluence with the acceptance criteria to review before refactoring something and a huge etc of things.
The real life for most projects is that business needs go first and it usually means "We need this done by [DEADLINE]" which leads inevitably to cut time in some of those things, so you need to choose.
Do you prefer extended dev time by using TS? Do you prefer to have unit tests? Do you enforce documentation?
There are different approaches that lead you to -almost- the same result, for example, if you take the approach of "everything is a component" in React, using propTypes is more flexible than strong typing your code, plus you add explicit definition of what is optional and what is required and so on, just to add an incomplete example.
It's not all black or white, it's not a "good practice", it's not a use TS or not use TS, it's a tech stack definition and it will be the correct one or not depending on those different metrics I add before and it may be a question on "how much TS do you want to imply in your project" and for which reason.
I'm adding 2 use cases from some months ago just to illustrate.
Real-time chat app with Node + React using Websockets
and persisting data in a MySQL database.
It was meant to be integrated inside a different webapp as stand-alone webapp.
React code is just an entry point to authenticate the user in context + the chat component (divided in two, the place where you type and the place where you read). Around 200 lines of code as much, you just deal with strings.
Node backend it's just the event emmiter, the persister (to store) and the reader (to get previous chat history), around 150 lines of code as much if you put the files together, again you just deal with strings.
There is no logical benefit of adding TS. You can fantasize with things like "if the project grows then...", "if bla bla... then" but the reallity is that this project will remain as is for it's entire life.
Service to handle bussiness logic
Between a React frontend and a headless CMS.
That's the objective truth about this regarding the metrics, but you seem like the one dev that cries at the back saying "but we HAVE TO use TS" (usually just because he's used to it and as a personal preference) and can't give any good reason for it to Architecture and Management people.
I don't know man, jsdocs, proptypes.. I see that too often as wishful thinking, because only one dogmatic guy of the entire team is keeping those up to date and consistent. Strict ts is more friendly for a mixed-level team because it puts less burden on Sr engineers during code review to always double check if "best practices" are adhered to (and reduces friction due to being code-blocked during the code feedback stage)
A codebase with outdated jsdoc/proptypes/etc brings a tear to my eye.
You can use a linter to ensure those are present and validate ts-pragma as well, so you can't have an invalid definition
Or you can not use all those things and just use one thing: Typescript :P
Sure it's an option that I follow depending on the use-case :)