TypeScript is like JavaScript but with no surprises.
I heard a long time ago about TS, great stories about how useful it is, allowing js...
For further actions, you may consider blocking this person and/or reporting abuse
Then you just don't have experience of working on large enough plain javascript object. Jumping into such project and changing anything is a scary proposition.
The only thing that will back you up when making changes is having in place some nice, solid automated tests.
I like to add typings in JSDoc (for JavaScript) and typings in Python as well.
You can do it to that level in TypeScript by setting
noImplicitAny: falseintsconfig.json; and then, you don't have to always add typings.But no, it's not the default settings.
To stray you away from TypeScript further, I would say that, typing in any dynamic languages (maybe apart from Dart and Julia), might give you a false sense of security. You should still write tests after that.
Still, I prefer to work with JS users who at least write JSDoc.
Sorry but this is just utterly false for so many reasons.
That's true. But then TypeScript is getting better.
The latest change is ability to make array and record indexing return undefined. (by settings in tsconfig.)
But yes, I will never trust TypeScript to be truly safe, nor truly strongly typed.
Yeah, don’t get me wrong, TS is still a VAST improvement over JS.
and if you combine types and tests, will make the code reliable?
If you have reliable enough tests, sure. And to be clear, I still think TS is a huge improvement over JS.
Having types of some sort helps me greatly in just writing functions, because it makes it much easier to remember just what data I'm messing around with. But I do tend to a functional/data-first style. So it reduces cognitive load way before you get to using tests/compiler to check things. And so, in fact, if your types are wrong your function/data manipulation will go wrong when you write it and a compiler/running tests are secondary things.
Could you list a few?
Incorrect types for open source packages, happens quite often
If you’re targeting the browser... Internet Explorer
Generics not working the way you expect them to in certain scenarios
There’s lots. It’s also just a superset of JavaScript, so any surprise JavaScript can produce, typescript can also product.
Thanks for sharing these points, Mat!
I'll investigate the cons of using TS 🤔
Don’t get me wrong, TS is a VAST improvement over JS, but it does have its own set of “gotchas”
To be honest, I don't use TypeScript yet, I just found it very interesting and loved by the community so... for that reasons I decided to write this, but I have in mind to start a little project to check his good points (and the bad ones too) 👏
I use TypeScript (and Prettier) instead of ESLint and Babel, actually. And tsconfig is quite simple and intuitive.
Though, of course, you can use all of these together.
I wouldn't use uncompiled vanilla JS, as it is inconsistent between browser and node (as well as unminified and unfeatured).
So, if compiled anyway, why not TypeScript?
ts-ignoreis superior toas anyYou can ban both of these with latest ESLint.
eslint-disableis superior to ESLint, its really difficult to catch unless you setup automated git monitor to track commit and warn usage of such features.Nonetheless, the idea of you CANNOT disable Golint sucks.
You diabolical...
I appreciate your taking the time to write this article - it is a brief and clear introduction to TS.
And, I find the fact that you call a function that adds two numbers "minus" confusing to the point of disturbing. Would you consider fixing the example?
Also, after reading the article, I still don't know why "I should type my next JS project".
What are some common patterns where using typed JS is a benefit?
I get that other devs like it, but why?
Thank you!
Thanks for the constructive critic, I will update the advantages of TS to make it more clear with some examples and statistics about bugs
I reply to another dev to a similar question so I will copy-paste the answer:
Yes, I guess you are right, I miss the point of the title during the process trying to explain how simple is to write in TS instead of JS.
As you can see with TypeScript we can define the interfaces for parts of our program, so we can be sure that they interact correctly. It means they will have clear contracts of communication with each other which will significantly reduce the number of bugs. TS + unit tests will do the code more stable, predictable and probably will reduce the amount of pre-release bug density.
Any suggestion to improve the example related to the function minus?
Hi Miguel, thanks for the reply.
Name the function “add” so that it does what it says.
What are some common places in a web app which benefit from typing and make the time investment of using typescript worth it? Examples?
Most of us don’t get type errors in our code. TS is a significant overhead. Why the overhead if no benefit? Adding busy work does not make me happy.
Why are all these developers so happy? Code examples where the extra hours of using TS actually save time?
After reading the whole thread my conclusion -
There are 2 types of people -
First - who likes TS / have used earlier and know how helpful TS is in Coding.
Second - Who don’t want to write extra pieces of code, So to justify their laziness they start giving excuses like Overcomplicated / Bloat / Better Alternatives / Example of closed projects.....
Nothing is perfect at the start, JavaScript also got multiple updates.
That's why we are developers, We evolve with time. If some new project comes that offers better than TS we will switch to it.
It's the same like - I will use Notepad because MS Word has spelling and grammar correction which is overcomplicated.
I started to use TypeScript when I learned Angular 4. At that time, I thought that I would be using TypeScript only for Angular Development, but as time progressed, the TypeScript found its way through the ReactJS and normal JavaScript Development as well.
I think the reason behind this is the strictness that do not allow the developer to get too flexible with JavaScript and allow the developer to write more readable and cleaner code.
Totally! That's one of the main advantages for me
Typescript is great in my opinion. I'm glad to be able to use it at my current client now. I do think the article focuses more on how you write typescript than explain why you should use it in your JS projects. Great article none the less! :)
Yes, I guess you are right, I miss the point of the title during the process trying to explain how simple is to write in ts instead of js.
As you can see with TypeScript we can define the interfaces for parts of our program, so we can be sure that they interact correctly. It means they will have clear contracts of communication with each other which will significantly reduce the number of bugs. TS + unit tests will do the code more stable, predictable and probably will reduce the amount of pre-release bug density.
Having types means needing to write less unit tests.
And they serve as documentation.
There's really no reason to not use a typed language.
Typing is not what developers spend most of their time one anyways.
Actually, thinking about this again, there is one very good reason not to use types. :)
For people that are just learning to program, learning types is less important than learning the mindset & how to debug.
Gotta walk before we can run. :)
I really like JSDoc! I've used TypeScript for a few libraries but for projects that don't need a build step, it's so simple to just edit your source from the browser devtools source panel.
You can still check your project "compiles" by running the typescript compiler over our JS source by adding
tsc -p jsconfig.jsonto yourpackage.jsonlike this. Here's my jsconfig.json -- the commented out rules fail now but it's on my backlog to clean up the code.It doesn't matter if I don't fully benefit from it, does it?
Don't be too serious and try to fight JavaScript.
Furthermore, I don't have a problem creating my
.d.ts.TypeScript advocates always seem to be up in arms when somebody suggests that they don't need types.
I'd like to turn the tables. I'm flabbergasted (well, not really - more like 🤦♂️) how people claiming to value static typing are championing a tool that eschews soundness.
No Soundness, No Business
Now Java dates back to 1995 and C# to 2000 but TypeScript didn't appear until 2012 - so what is TypesScript's excuse? Gradual typing of JavaScript code. So that is worth a tradeoff that essentially undermines the perceived "safety" of static typing?
Bottom-line - anybody who is actually serious about static typing wouldn't be using TypeScript for this exact reason but something more like ReScript (and simply accept the additional pain of JavaScript interop).
TypeScript is simply a super linter that requires syntax extensions to normal JavaScript (making it not parsable as JavaScript unless you stick to JS Doc TS) to do its job. TypeScript is a Subset of JavaScript - it's only a superset in terms of syntax but not in terms of capability.
TypeScript is popular:
because of IDE (VS Code) integration, most notably Code Completion. It's humorous how for years Java users have been denigrated by their peers for their reliance on IDEs to work around the warts and boilerplate of Java - and TypeScript/VS Code are gaining popularity and praise for those same features - TypeScript could only succeed because VS Code (and the like) made the additional ceremony bearable.
because it gives developers coming from Java/C# a false sense of familiarity - which is actually dangerous because they keep operating on a mental model that is something other than JavaScript, setting themselves up for disappointment.
And finally the term "strong typing" is almost meaningless:
i.e. Erlang is dynamically typed but considers itself strongly typed because it does not coerce types.
When people use the term "strong typing" they usually mean "static typing"; when they use "static typing" they feel "safe" even though that safety actually requires "soundness".
Yes, types improve code.
But the primary benefit comes from thinking and designing in types, i.e. type-driven development. That can be practiced in a dynamically typed language - simply using a type-aware tool doesn't automatically yield those benefits.
Life After Business Objects
Where did I write that?
Anyways, at least for TS, having the right static type doesn't mean having the right runtime type. So you need to write tests for that. And those tests will also catch the same bugs that the compiler could catch.
You can set up ESLint to catch cases like this - then it will warn you to add return type to a function.
But finally all .ts files will convert into .js files so they can work in browsers.
Then what's the exact advantage of Typescript.
I have coded something in typescript,
Let a:string = 'some string';
And I tried to change that value using input[type='number'] tag.
Then 'a' value is changing even the given value is 'number'.
Can you please give me more brief about typescript?
Thanks
That fuctions could have been written by a child.
What about if you instead of providing such a ridiculous examples, shows us an example of how would you type a component generated from a render props that takes a function props that expects a ref as a paremeter?? Would typescript still be so fancy?
OK, I'll bite.
Flow offers many of the same advantages as Typescript. You can specify the shape of objects, define common interfaces, and so on, and Flow will pick up on type-related errors for you.
I'd also argue that using a language that extends Javascript is potentially risky. You can always bet on Javascript being available in the future, but languages that compile to Javascript have a rather shaky history (can't be too much support for Coffeescript left, for example). Plus, Microsoft's track record on embrace, extend and extinguish is something to be wary of. By contrast, Flow was always implemented as just a set of annotations on top of Javascript that can be stripped out by a simple Babel transform.
For those reasons I opted for Flow over Typescript, and I have no plans to change anytime soon. I'm of the opinion that it's a better solution to the same problem, and provides similar benefits.
I will say that I regard both Flow and Typescript as transitional solutions - adding equivalent functionality to the Javascript language would be a far, far better solution.
Type correctness does not guarantee program correctness.
You need tests anyways, types or not types. If there's a typo the tests will fail, so in this specific case I'd say that types may be redundant.
I think I'm just gonna make the jump from using jsDocs for typing (no compilation so not as robust I guess but somehow nicer) to ClojureScript.
It is also possible to use Babel, tscomb or Flow.
Hey man, if you need to introduce a whole new language only for catching typos, good for you! I'll keep using the eslinter
Wow, you just said everything that i think about typescript especially the comparison with kotlin.
I thought i was alone in this opinion but you prooved me the oposite, thank you!
Then you just dont have experience of working on large enough plain javascript object. Jumping into such project and changing anything is a scary proposition.
Great Article ✨ , a must read!
Thanks! 🙌
I love Typescript mostly for Typedefs which cover 95% of all JavaScript libraries. Immediate API discovery as I type.
verry good dude
Any one knows this font?
i.imgur.com/mUUZcnU.png
I can understand your point, the thing is if your client has already a project with installed ts there and with what type of client you are working on :)
Well, most of projects are with ts. Almost each framework has ts integration as well.
For 'your' not for your client's projects, at least not for big projects :D other things are true
TypeScript is going to gain more popularity this year.
I think, I can't use TS in Svelte
It seems since July 2020 Svelte supports TypeScript 👌
svelte.dev/blog/svelte-and-typescript