Not anymore. True, when TS was first introduced in 2012, it had features like classes, still not available in JS by this time. But JS had come a long way since then, and now TS is struggling to keep up. If there is anything missing in JS, there is a babel plugin to do it.
Well there a couple of things that I've pointed out which are still not present in javascript. And moreover, javascript has been copying typescript features such as the ? optional chaining operator. Which shows TS features are useful and not overkill.
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
Wait my bad... I thought in reply to the comment it means what extra does JS give that TS does not provide.... because you said so in the previous thread(7 tips for clean code). I've mentioned in the post the extra features TS provides
For example, public, private and protected fields, abstract classes, optional chaining and nullish coalescing(which was copied by JS) etc
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
if was "copied" by JS is already on JS so let's talk about the others. do you think they can't be implemented using JS? codepen.io/joelbonetr/pen/xxdYdWb
this is -maybe- a vague approach but I insist that if it can be done in TS it will probably can be done in plain JS (unless it's a strict compile time job)
But in fact, do you really need this?
JS is used to build components in the frontend (which would be better to keep them as isolated and uncoupled as possible) and APIs in the backend (which are metaphorically also isolated components that handles a specific task).
If you are going to code a monolith run and embrace TS but if you are in microservices then... you can simply use JS.
Neither you need OOP, there's no one paradigm to rule them all, it will depend on the project needs. If you put your preferences over the project needs the result will be worse. It's like a mechanic engineer using always the same engine for all the vehicles he design.
If you are going to code a monolith run and embrace TS but if you are in microservices then... you can simply use JS.
Ah for microservices, it will be difficult to keep track of various types of arguments across multiple microservices and it gets tedious to write and read long comments.
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
wdy need to track those types of arguments? when you create or consume an API there's a contract (on REST APIs) or a Schema (in GraphQL APIs) so you'll know which kind of data you are retrieving at this exact point.
BTW most of time you don't need to have a specific type.
Imagine you retrieve data from whatever source and you need to print this data inside some node element, something like
/*
* Receives an object with the props
* name
* age
*/
function doStuff(data) {
return `Hello ${data.name}, we'll send you a cake for your ${data.age} birthday!`;
}
Can you spot any issue for having dynamic typed props here?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well there a couple of things that I've pointed out which are still not present in javascript. And moreover, javascript has been copying typescript features such as the
?optional chaining operator. Which shows TS features are useful and not overkill.which things can TS bring that JS lacks? please explain or make a list
Yeah even I want to know this!
so If you don't know that why you add this argument? LoL
Wait my bad... I thought in reply to the comment it means what extra does JS give that TS does not provide.... because you said so in the previous thread(7 tips for clean code). I've mentioned in the post the extra features TS provides
if was "copied" by JS is already on JS so let's talk about the others. do you think they can't be implemented using JS?
codepen.io/joelbonetr/pen/xxdYdWb
this is -maybe- a vague approach but I insist that if it can be done in TS it will probably can be done in plain JS (unless it's a strict compile time job)
Also take a look at:
stackoverflow.com/questions/55611/...
But in fact, do you really need this?
JS is used to build components in the frontend (which would be better to keep them as isolated and uncoupled as possible) and APIs in the backend (which are metaphorically also isolated components that handles a specific task).
If you are going to code a monolith run and embrace TS but if you are in microservices then... you can simply use JS.
Neither you need OOP, there's no one paradigm to rule them all, it will depend on the project needs. If you put your preferences over the project needs the result will be worse. It's like a mechanic engineer using always the same engine for all the vehicles he design.
Ah for microservices, it will be difficult to keep track of various types of arguments across multiple microservices and it gets tedious to write and read long comments.
Or use JSDoc...
wdy need to track those types of arguments? when you create or consume an API there's a contract (on REST APIs) or a Schema (in GraphQL APIs) so you'll know which kind of data you are retrieving at this exact point.
BTW most of time you don't need to have a specific type.
Imagine you retrieve data from whatever source and you need to print this data inside some node element, something like
/* * Receives an object with the props * name * age */ function doStuff(data) { return `Hello ${data.name}, we'll send you a cake for your ${data.age} birthday!`; }Can you spot any issue for having dynamic typed props here?