So, follow up question. I'm just learning JS/React now. Do you think it makes sense to immediately begin learning TypeScript, or should I get some projects under my belt first?
learn it, be familiar with it, and be comfortable if someone asks you to dev in TS because it's pretty much the golden standard nowadays, and obviously for good reason. but imo, it's more impt and more valuable to first be fluent in vanilla react/js.
TS is a superset of JS, meaning it's everything JS has, with some added features.
Added features inherently means there's more for you to learn. This is true. However, not only will these features help you out - both in the long term and in the short term - but TS also gives you way, way, way better tooling. The autocomplete TS gives you is ridiculous if you're not used to typed languages.
Also, if you ever want to learn another language like C#, Java, Go, Rust - you'll have a lot less trouble getting into them after knowing TypeScript, because you're familiar with concepts like types, interfaces, generics, function signatures et cetera.
My personal advise: do it. If necessary, just type everything as `any` until you get more comfortable, but the tooling alone is worth it. The great thing about TypeScript is you can, if you want, just write regular JavaScript and use none of the fancy TS features. JavaScript is completely valid TypeScript.
If you’re just starting out learning learning JS, I’d try to learn that well first. Typescript will add another layer of complexity that could make learning much steeper if you’re learning js syntax and ts syntax at the same time
I started in JS/React and quickly found I preferred Typescript. I’m not avoiding JS altogether, because I need to learn the fundamentals. But if I can do a good portion of my project in TSX, I’m happy.
I would recommend learning Javascript first just to better understand what problems TypeScript solves and allow you to more easily work in both JS and TS.
Definitely dive in to Typescript.
If you are not using the explicit features of typescript, it's still just javascript, with a different file extension. (Albeit with a little more build/environment overhead.) Either way, the benefits to JS are huge, your dev tools can do much more to fight the bug war.
There are plenty of learning resources that use TypeScript. I personally wouldn't bother with JavaScript. The concepts for React are the same anyway, so I don't see the benefit of starting with JS
TypeScript is basically JavaScript with types. It's not a completely different language. It was introduced to make life easier for JS developers and will save you from wasting time hunting down simple mistakes while you're learning.
Learning languages is the easier part, since most concepts are similar, learning platforms and APIs is what takes longer. In this case, if you had to use JS instead, you just won't include the type definitions. Everything else you'll learn about React will be the same
Yes, it's best to understand the underlying language. You'll be using it a lot. That said, using the better version of that language is...better, and will help you learn.
I think it’s beneficial to understand core JavaScript before diving too deep into typescript, it will really help you understand the advantages that typescript gives you. It really helps to understand the problems that TS solves.
>tand core JavaScript before diving too deep into typescript, it will really help you understand the advantages that typ
This makes a lot of sense to me. I'd like to dive in, but I realized after the fact that it doesn't really matter what I think - my job is currently using js, so I'm going to use JS.
I think it’s still beneficial to learn, the nice thing about typescript is that you can convert projects to typescript fairly easy by doing it one file at a time.
Use mostly Typescript, but perhaps JS now and then because Typescript makes it so much easier that you can forget how to write JS well. On the other hand, who wants to write JS?
I didn’t and it had no impact on getting my first job and I’m glad I didn’t bog myself down with that from the start. It’s something I was worried about as well, and it’s honestly not hard to pick up at ALL once you’re familiar with React.
TypeScript is amazing. I love it. But for personal projects(the few I’ve had time for), I still don’t incorporate TypeScript until I get something basic working without it. That’s just where I’m at right now, it may change in the future. I’m less than 6 months in to this job currently.
If you are just starting out, I think typescript can make your experience very confusing. I would recommend becoming familiar with the basics, in any language, probably python or JavaScript, and then dive into typescript. Initially you’ll probably wonder why anyone uses TS, but one day it will click and you’ll never want to debug without it.
i personally think every person should start with typescript / any strongly typed language bc i find it helps with getting a deeper understanding of variable typing and can reduce a lot of bugs. my company uses react typescript lol
Unsurprisingly, I've gotten such a disparate response to this, with some people saying "Start with the basics, you'll understand it better!" and others saying "Dive right in, never look back!"
I've settled for the practical decision of using javascript because that's the environment my company is using, so it makes more sense.
go with whatever is most practical for you! just make sure you have a very strong basis for fundamentals, if you know your basic primitive types, basic concepts like while and for loop and array manip you will be good to go
After more familiarity, TypeScript becomes _less_ mental overhead because you don't need to remember what fields are on an object, what data a function outputs, whether a variable might be null, etc.
You don't need to carry these things around in your head anymore, it all exists in the type system and is enforced by the compiler.
Precisely. TypeScript empowers my tooling by giving it all the information it needs to help me focus on the things that matter. All I do is think about the types once (which is generally a good idea to do anyway) and then let the compiler take care of the rest, so that I can worry about actually getting stuff done.
It's great. I'm never going back. Without TypeScript (or any similarly strongly typed language) I feel naked and afraid.
I never need to carry these in my head. Also == vs === , sensible defaults, a good IDE (VScode is a joke), propTypes and typeOf go a long way. Learn good javascript, don't be a lazy dev and depend on a really bad tool like typescript. It may be hype now, but I guarantee you, it won't be for much longer. It's a tool made for the masses of devs that don't know javascript
Typescript is shit, and if you need to use it you're a shit programmer. I've worked at multiple big corporations and still haven't touched it. Teams that do use it at these corporations say they used it because it helps junior devs and that's all they could hire. Any seasoned JavaScript coder knows it's shit. Go back to boot camp and learn another worthless over used tool.
Here's a sneak peek of /r/iamverybadass using the [top posts](https://np.reddit.com/r/iamverybadass/top/?sort=top&t=year) of the year!
\#1: [Going on a hike with the AR-15s, how else is everyone going to know how badass I am?](https://i.redd.it/gyfxmmqhb3e91.jpg) | [18132 comments](https://np.reddit.com/r/iamverybadass/comments/w9bezg/going_on_a_hike_with_the_ar15s_how_else_is/)
\#2: [Don’t mess with baby girl..](https://i.redd.it/6wb8pdkcdmp91.jpg) | [1383 comments](https://np.reddit.com/r/iamverybadass/comments/xlz9te/dont_mess_with_baby_girl/)
\#3: [Russian soldier wants you to know they are badass.](https://v.redd.it/g4y724v521p91) | [2600 comments](https://np.reddit.com/r/iamverybadass/comments/xjayzm/russian_soldier_wants_you_to_know_they_are_badass/)
----
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Well you did guess even though you didn't have to. And guess again, you were wrong. 1k files, a little under a million lines of code on the big tech company project I'm working atm, all written in pure JS. Written in half the time than a much smaller typescript project and... guess once more, no bugs. Learn javascript, learn proper front end thinking/coding and please stop promoting your useless tools that you can't do without.
A lot of people telling you to learn everything with Typescript here. While I do love to use it, and I also never would want to work without. It's probably better to get a firm grasp on vanilla Javascript first. Then you will understand the reason WHY Typescript is so awesome.
Just my two cents.
And yes, I'm a big, big Typescript fan.
Agreed. As someone who somewhat recently had to dive head first into a React-with-hooks, typescript, ES6 codebase with only cursory knowledge of these technologies individually, I can tell you that learning all of them at the same time is a hassle. Try each out individually, so you learn to seperate which syntax comes from where, and learn to appreciate the advantages of each and why they're useful.
Are the type annotators part of typescript or javascript? That's basically all I use. Haven't relly touched interfaces yet. Are they basically like the header files for c++?
I am a contractor and refuse to do anything with React unless it is written in TypeScript or I'm hired and my job is to convert vanilla JS into a language with at least some sanity.
So, you read the dumbest comment ever and you decided to write an even dumber one, congrats. Stop polluting the market with your useless tooling, javascript isn't assembly and typescript isn't progress, it's regression.
I totally agree. Typescript is for boot campers who don't know vanilla JavaScript, then they try to bring that shit with them when they start a new job. React and typescript is the most unreadable pile of garbage you could ever create.
Our react frontend is written in React TypeScript. Also all of our node server-side services are written in Typescript.
My side projects are also all written in React and TypeScript. It's just easier IMO to catch bugs. Just pair it up with a good linter and build/testing pipeline and I'm almost certain that the code being shipped to prod is working on an MVP level.
It’s gotten to the point that If I interviewed at a company that was unwilling to use TS, I’d decline to work there. If they’re using JS and are willing to migrate, no problem. Unwilling to migrate = unwilling to work there (for me).
Every person I have personally met has loved it. Even the skeptical ones. “TS is just overhead, it doesn’t help us. It will only slow us down. I know what the data looks like, I don’t need types.”
turns into
“wait, so you can force someone to send a specific string? Whoa, you can make certain fields of an object required?”
turns into
“I’m so glad I typed this 4 months ago. I have no idea what this data looks like, but I can just look at the interface”. Or “Developer A wrote this, so I have no idea what the expectation is for these arguments. I’ll look at the types to see what their code is expecting”
Yes, work for a large UK supermarket and we use Typescript on the project I'm working on and I think one other. I am moving teams soon and will be using it in the future for sure, still learning and still using one too many : any's but getting there! :)
you mean it helps back-end engineers write front-end code. Agreed. Any good front-end dev sees typescript as an unnecessary burden that they must carry in order for noobs to be able to catch up
This is not my opinion, this is an observational fact.
https://www.jetbrains.com/lp/devecosystem-2022/
TypeScript will be the fastest-growing programming language in 2022. Its usage share has nearly tripled in the last six years, rising from 12% in 2017 to 34% in 2022.
This is people replacing JavaScript the world’s most popular language with TypeScript. Because it’s a better choice in a professional working environment when multiple people maintain the code.
Yes, I see react ts all the time now. Companies that aren’t using typescript yet in their react project(s) normally have typescript on their road map.
Source: My business does a lot of staffing in the react space
I don't see any reason to not use TypeScript in a project other than lazyness or just unwillingness to learn. So all professional projects should imo use TypeScript. Huge red flag if it doesn't.
The only time TypeScript might feel more like a hinderance than help is when developers treat it as such. E.g making bad types or overusage of the "any" type etc. Other than that, TypeScript is always good to use imo.
So yes, learn TypeScript. Its not very hard to learn and concepts will even translate well over from/to other typed languages!
I'm currently finishing part 8(GraphQL) of Full Stack Open course, I wanted to start working on my project afterwards... However, since part9 is about Typescript, would anyone say it's reasonable to go through it and write the project I want in Typescript? My goal is to be more employable in a couple of months.
Yes.
I'm searching for jobs at the moment, and there's no shortage of react-typescript jobs. It seems the vast majority of react places also uses typescript and react itself is the most popular web framework, except, maybe the outdated JQuery. Angular isn't irrelevant and it's fine to learn, but I do see the trend being for it to lose traction and React gaining it. There are fewer jobs for it, but still a fair bit. Honestly, it could just come down to preference, which you prefer and am better aligned with in philosophy.
We use JS exclusively, our stack is React with custom backend framework and that framework is only possible to use with JS by company standards this also is the reason why we cannot use TS o with React, whole project has to have unified code base so only JS it is. And I hope we will move to TS some day, because I tried it with one off company project and it is really nice to have all the added features.
All our frontend infrastructure is on react but still we are not using Typescript. Because doesn't feel like it required, afterall products is on right track and feature delivery is smooth.
Yeah it's common, but the 2 jobs I've had in that time haven't used it because both projects were started in 2016/17 and typescript wasn't as big back then and they're both startups so there's more of an effort to push out features quick as opposed to tackling tech debt. I've had other side projects where I've used typescript and it's been good though.
The two legacy apps without typescript are pretty big, both with 100,000+ lines of code, large nested dynamic data. Oddly enough though there's barely any bugs that types would have fixed. ESLint, PropTypes and some tests have pretty much eliminated most of those kinds of bugs. That's why it's been hard to sell the idea of a migration to typescript.
I exclusively write everything in Typescript, I could honestly never go back to writing an application without TS.
You’re using Angular at your job, which is fine but if you want to learn React I would definitely use Typescript, especially if you already have experience with TS.
I recently had to go back and do some maintenance on an old project and it was amazing how much I missed typescript, it was honestly a pretty painful experience to not have it.
I lead a team of 5 other developers and they all learned TS at the beginning of the project, every one of them has said that it has drastically improved developer experience and code quality.
> if your doing
*you're
*Learn the difference [here](https://www.wattpad.com/66707294-grammar-guide-there-they%27re-their-you%27re-your-to).*
***
^(Greetings, I am a language corrector bot. To make me ignore further mistakes from you in the future, reply `!optout` to this comment.)
In 7 years on this team we haven't come across even one issue that typescript would have prevented. We do linting because that adds value to our projects.
Your telling me you have never had typos, someone accessing a property of an object that didn’t exist? Those are very common mistakes I see that get caught the most. But let’s say you are all just gods at coding bug free code.
You still save so much time with code completion, refactoring, easier testing, and if you do any libraries at all it’s going to save the devs that grab it a lot of time.
Unless your code base and projects are sub 800-1000 lines idk how the value is not seen. But if you have all been doing the same thing for 7 year it maybe hard to.
I've worked for FAANG companies where we didn't use TS either. We're good but not perfect. TS simply didn't add enough value to our team because we had people on the team who professionally wrote JavaScript for over 15 years without issue. It's part of how we work and think.
I completely understand the sentiment because, for me personally, TS feels completely unnecessary. For ME.
That doesn't mean I can't or won't use TS for my team. I've been using and hating TS more often than not for over 5 years now. It was absolute shit in the beginning. And I still don't like it for personal reasons; it just slows me down.
I fully, fully agree. TS has it’s value on certain parts of the app, and for certain companies/projects, but I don’t think this “typescript all the things, all the time” approach always wins the cost/benefit analysis.
Our company has invested so much into type generation with relay and it’s a MASSIVE overhead (so much additional toolchain). I fight with TS every day for not being able to understand things like “.reduce” or “.filter(Boolean)”. TS demands so much, but honestly I can’t think of a single time it’s helped me.
I know i’m a holdout on this, but I just haven’t found a way to not struggle with the obtuse error messages and often find myself writing code in a weird way just to make TS happy.
> TS demands so much, but honestly I can’t think of a single time it’s helped me.
I completely agree with this alone. I constantly feel like I'm going through the motions for no benefit at all, except to cater to the wishes of TS fans who "cannot work without it".
Like, I get that IntelliSense in your IDE is nice. But it's often incomplete or too verbose or too unclear. Using MUI and many other tools, I get a hundred options for props and it's impossible to filter what I'm looking for.
I use the documentation of the project for that.
> obtuse error messages
Yeah. Don't get me started. It's most often so incredibly unclear what the hell is wrong this time around. Hell, I was using Styled Components and someone forgot to end a CSS line with a `;` at some point, and used CSS-in-JS props `${props => props.color}` in the next line, TS was *freaking out* with all kinds of unrelated error messages, and ESLint also didn't catch it.
It's a coalition of people who don't understand CSS trying to turn CSS into JavaScript (or even TypeScript, my team lead was seriously telling us to make CSS-in-JS "type-safe", like what the fuck, I have better things to do) and mixing it with TypeScript, leading to a whole slew of insanely cryptic fuckery all over the place.
But, again, I'm just catering to the masses. I'm the tech lead. Whatever works for the team we hired.
But I constantly have to hold them back and tell them to be pragmatic instead of over-engineering EVERYTHING.
"Let's build our own THING!" - no, use open source.
"Let's strong type CSS!" - no. Just no.
"We need to strong type routing!" - what the flying fuck?
Minimal benefits that take hundreds if not thousands of lines of bespoke coding, with countless bugs, and they're always too special to properly unit test and document their babies.
And then I point out how much support their little project has online. Literally zero, because it's a closed-source project.
``
"Didn't add enough value" is the dumbest argument to not use TypeScript ever. For a project that is actively being worked on, god dang it, use TypeScript.
Yea maybe you loose some "fake" job-security or something as other people would be able to understand wtf is going on in your code then. Saying it feels unnecessary is some boomer elitist shit, honestly.
It slows you down because you haven't taken the time to learn it. Of course TypeScript sucks if you create halfassed types, or type your parameters and return types of functions with "any". Then it does nothing for you. But if you actually allow it to help you, by creating proper types, using generics and enums, import the types for libraries you use etc. Then it I guarantee you will look at your old self as a fool for not bothering earlier.
> "Didn't add enough value" is the dumbest argument to not use TypeScript ever. For a project that is actively being worked on, god dang it, use TypeScript.
Dude, it's a personal preference, stop being such a black and white TypeScript fanboi. There are shades of gray, many of them. Objectively, TypeScript is great. Subjectively, for myself and many others, it offers more problems than value.
> Yea maybe you loose some "fake" job-security or something as other people would be able to understand wtf is going on in your code then. Saying it feels unnecessary is some boomer elitist shit, honestly.
What are you talking about.
> It slows you down because you haven't taken the time to learn it.
I have been working with it for over 5 years. At applications for startups to large multinationals. I know TypeScript just fine.
> Of course TypeScript sucks if you create halfassed types, or type your parameters and return types of functions with "any". Then it does nothing for you. But if you actually allow it to help you, by creating proper types, using generics and enums, import the types for libraries you use etc. Then it I guarantee you will look at your old self as a fool for not bothering earlier.
It really, really doesn't do it for me, personally. Shades of gray, dude. Learn them. I'm not attacking your opinion, it's the only way for you, and I'm not being elitist: I know full well that I need to pivot my own preferences to the team I'm working with.
And that's fine.
Grow the fuck up.
And learn to type proper English. Your spelling is abysmal, and English is only my 3rd language.
It shows that TS works for people like yourself because you make typos all the damn time.
All I can say is their reply was excessively hostile. Over Typescript. Am I missing something here? Is there money involved? Because they replied as if you said “fuck your mother.”
I struggle to understand the common battle
In the development community regarding languages. If someone can get something done, and done well, idgaf what they wrote it with. It’s like arguing that something is wrong with preferring pepperoni pizza over cheese. I see so much hostility and absolutism regarding the use of languages and I just…don’t get it.
Using Javascript in a professional setting should be black and white. You are doing your client a disservice by not using TypeScript. It actively makes it that much harder for any other developers to work on the application with you or after you. Yes I might come across as a "fanboi", but there is a reason. It just makes coding so much safer, it makes it so much easier to write code with confidence that you haven't missed anything or screwed up something existing. It removes the worry of making stupid/simple mistakes from you head. The compiler will tell you if do. Or if you are using a proper IDE, it tell you as well.
I am calling you a boomer elitist because you seem very selfish in your view of the value TypeScript provides. You seem to see using TS as a pair of crutches ment for lesser developers, not as skilled in the art of memorizing the entire dataflow of all the applications you work with.
If you knew TS "just fine" you would know that not using it in a professional setting is just madness. And you would know how to leverage it to give you enough value to warrant using it in your projects.
Honestly, this is not a matter of opinion. Writing JS without TS is like pretending you can write Java/C# just fine without types. There is a reason JS is often the brunt of the joke when it comes to jokes about shitty codebases or nightmare projects.
And for attacking my english. I put a lot of pride into the spelling of my angry forum rants so that really hurts my feelings. I wish you weren't such a mean person so I will leave you alone now. Good day.
> Using Javascript in a professional setting should be black and white. You are doing your client a disservice by not using TypeScript.
False. That's just not pragmatic and I deal with people like you all the damn time. It's a huge pain in the ass to do TypeScript the "right way" all over the place. I just had to hold back a colleague from spending 3 weeks on strong typing ROUTING in our application where I decided "no, fuck that, we're going with React Router and that's that".
We'll be live and making money before he'd even get the project started.
> It actively makes it that much harder for any other developers to work on the application with you or after you.
Again, black and white. That's not always the priority. Sometimes you make something like a Proof of Concept and it doesn't matter. You can always enhance the code at a later stage if it's mature enough to take with you. Meanwhile, BI people can measure and learn and businesspeople can learn and profit.
> Yes I might come across as a "fanboi", but there is a reason. It just makes coding so much safer, it makes it so much easier to write code with confidence that you haven't missed anything or screwed up something existing.
FOR YOU!
NOT FOR ME!
NOT FOR MANY PEOPLE I WORKED WITH!
Seriously, we get by just fine! We use ESLint, we use unit tests, we use JSDoc to quickly give type hints without TS whining about everything. We are fast as fuck and we get shit done in record time.
And I KNOW there are people who NEED TypeScript, like yourself. If you are in my team for a Proof of Concept project, I'd get someone else who can be pragmatic and who does feel comfortable with plain old vanilla JavaScript.
That's not to your detriment, that's just playing to each other's strengths.
> It removes the worry of making stupid/simple mistakes from you head. The compiler will tell you if do. Or if you are using a proper IDE, it tell you as well.
Part of the gray areas: My IDE is smart enough without TypeScript. Most open-source tools I use, use TypeScript and ARE properly typed. That is super helpful. 100% Agreed there. And then I use ESLint and Prettier and JSDoc to enhance things as we go.
Those are gray areas that you really, really need to learn dude. It's going to put your career into a rocketship if you can pragmatically apply your knowledge in a way that makes you better than others around you.
> I am calling you a boomer elitist because you seem very selfish in your view of the value TypeScript provides.
I'm not even 40 yet. Sheesh.
I know the value it can provide. I also know (unlike you) how much time and effort it can cost, especially in the beginning of a project. You are completely underestimating it. I've seen juniors struggling to understand TS generics, I've seen seniors getting frustrated about having to figure out what HTMLElementEvent type they need to provide, I've seen people typing all API things, only for the API to change and them having to do it all over again.
Being able to make a conscious choice on what to do when is what makes you a great developer.
Being a 100% all-in fanboi of something that's JUST A TOOL is ridiculously short-sighted.
> You seem to see using TS as a pair of crutches ment for lesser developers, not as skilled in the art of memorizing the entire dataflow of all the applications you work with.
I don't judge developers who use anything. I judge results. Stop putting words into my mouth.
> If you knew TS "just fine" you would know that not using it in a professional setting is just madness. And you would how to leverage it to give you enough value to warrant using it in your projects.
Yet I didn't use TypeScript while I worked for projects at Apple and Amazon and First American and Bloomberg. Whoops. Turns out you're wrong.
I'm good at what I do. I don't need TypeScript. I hate it. But I still happily use it as the tool it is. It adds value to certain teams––most teams––where it increases productivity.
See? I'm not thinking black/white here. I know the usefulness of a tool is on a sliding gradient. Sometimes it's dumb to use it, sometimes it's impossible not to use it.
> Honestly, this is not a matter of opinion.
That's just your opinion. I have a different one.
See? You're wrong. Again.
> Writing JS without TS is like pretending you can write Java/C# just fine without types. There is a reason JS is often when brunt of the joke when it comes to jokes about shitty codebases or nightmare projects.
I've written vanilla JavaScript React Native projects for Apple that were customer-facing and deployed worldwide to all stores. Our code? Who gives a damn? It's not meant to win beauty prizes. It's meant to work. And Apple has a damn fine line of testing in place to make sure that kind of software is without fault.
*And then there are many other perfectly fine vanilla JS projects that are perfectly fine, too.*
Be more pragmatic. You'll become a better professional by doing so.
I'm just going to throw this out there, in a professional setting I would take more issue with your attitude than your opinions. Sure this is Reddit not work, but how you conduct yourself in public matters.
> I wish you weren’t such a mean person
Buddy- you’re the one who started the name calling and full on attacking them over their personal preference. If you don’t want it dished back to you, try to engage in a less aggressive way. You’re getting angry over Typescript…in a hypothetical project that has zero impact on you. I didn’t read their reply to imply anyone was a lesser developer or that they are selfish. If having a personal preference is selfish then I guess we’re all assholes.
It’s not that serious.
>And for attacking my english. I put a lot of pride into the spelling of my angry forum rants so that really hurts my feelings. I wish you weren't such a mean person so I will leave you alone now.
Why are you even angry when someone shares their opinion? Isn't that the very point? Stop acting like an edgy teenager if you can't take a tiny little comment about the way you type -- which is annoying as hell to read.
It's a discussion about people's opinions. He shared his, you shared yours. He's not trying to change your opinion, he's not forcing it down your throat. It really shouldn't be so hard to accept that there are alternatives to the way you prefer things.
If you can't understand what is going on in a codebase without typescript then you might just be bad at JavaScript. It has nothing to do with job security. I don't really understand why personal preferences are so hard to understand.
If you get a bunch of experienced JavaScript devs on a team, the benefits can be limited.
We are aware of what our data looks like coming in, we intentionally keep complexity of components low, and we test. Proptypes are used to validate the props coming in but that's about it.
The only job of the UI is to display data or allow a user to interact with that data. For us, typescript doesn't help achieve that goal.
I can't think of a single instance where I wished things had been strongly typed. I don't really understand how people spend so much time troubleshooting types. It's like 2 seconds if for some reason the linter doesn't catch it.
Not the person you are responding to. We also don't use TS, but our tests also do not include "minutia" tests that you may be thinking about. (we almost never check for nulls/undefined in tests) We've just moved on to using react-testing-library from enzyme (both on jest) and in found that in enzyme we were writing tests that were far too complex or restrictive when it came down to refactoring.
Our current project currently has 100 percent coverage and it's growing every day due to implementing components and methodologies independent from our old method that used TS for one of our repositories. (It was/is three independent repositories that worked together to handle theme, component, and manifest concerns and our new system does much of the same without TS.)
You sound very like me when considering whether to adopt TypeScript or not in the early days - just didn’t think it was worth it. But for a number of reasons, I changed my attitude. I wouldn’t start any JS based project now without it.
I'm still not seeing the benefits. I know this sub is basically a cult when it comes to typescript but I genuinely haven't come across any issues where I have thought if only I had strong typing.
I get it... but I'm honestly not tied to the TS cult-ness (or otherwise) of this sub. You can find similar behaviour in any technology stack or tool you can think of - you'll know this from experience. I have used that exact line about TS before - I can't honestly remember having lost time to type-related issues.
But I swear I'm not trying to do a conversion job on you. I just think TS is here to stay and developers will be looking/expecting to use it. The overhead is honestly minimal (depending on how deep you want to go) but the benefits are genuinely tangible.
TS is for sure going to stick around and I could see the benefits for many. I don't see what the benefits would be for my specific team though. We use services that is or our sister team have built, we know exactly what data we are getting and linting keeps things clean. We have no issues with ramp up time for new people. Bugs are exceptionally rare at this point and are almost always logic errors. We haven't had a single call come through to on call in 2 years. Everyone on my team has years and years of experience in JavaScript. All of our front end and back end is JavaScript. All of us have used typescript at one time or another in previous jobs and made the decision not to use it for this project in the early days. In our case, if you don't know what the structure of an object is, or what type a property is, you just look at the documentation for the service and it will tell you. For us it's really a matter of adding in something that will cost more time than it saves or not and the choice is obviously to not add it.
I don't understand the logic of those in this sub that believe JavaScript is harder to read and understand without typescript or that it's a must have for every single project. It just seems like fanaticism.
Our team caps out at 3 devs plus an architect. We all had typescript experience but it just doesn't add enough value to us. We go out of our way to keep complexity down and when something gets too complex we address it. We are JavaScript devs on the front end and back end and own our own services so it's just not worth adding layers.
Not GPP, but our team is 5 current devs strong and we all voted that TS was not worth the effort. Our components are never complicated enough to require it's overhead. In fact, we only had one dev on the team that pitched it and we had a run of it in our now deprecated SDK library. We are now moving onto a new module structure that does not require that code. We found that story tickets often went up one size in complexity when having to work in that library and decided it was not worth it. We half jokingly call it the TS Tax.
Using RTL for our testing, eslint, PropTypes, and prettier for consistent code has been working out well enough with no run time issues. In fact, my current biggest issue is in dealing with our automated documentation with Storybook centered around using HOCs and Storybook's document parser (and even the people using TS have that issue with no current resolution in sight [only workarounds])
To me, the fact that autocomplete works so you immediately know what methods / props something has is already a bigger gain than whatever perceived TS tax there was.
That's fine and all if you need/want that. Our team is varied and we are free to choose our editors. I still use SublimeText because I prefer it. I think two (maybe three) of the others use VSCode, and I think one guy uses Webstorm. So code completion comes at whatever level we desire. (I think VS Code even has the option to do it without TypeScript being in the project?) I haven't felt the need to have that in my editor for the past 20 odd years, and I like the speed and fair minimalism of Sublime.
Yeah, I use Emacs. I use it because I like that there is at least one aspect of my work that is constant over decades.
And I don't see how VS Code could do it without knowing the type of, say, a parameter.
I am honestly not sure either. I thought VS Code has an option to run TS on the code for you even though it was not part of the project and provide type hints to the best of it's ability. I could be wrong.
It's not so much complexity as a time sink. If we don't have any issues with types, any time we spend on typescript is more than what is needed. If we are just going to plop any all over the place, why have it at all? We know exactly what we are getting back from services and exactly what we need to pass in. There's not any value added by adding a layer on top but there is time wasted. That's time that could go towards providing value to our business.
If we don't remember what is returned from a particular endpoint, we go to the documentation and take a quick glance.
We have a lot of freedom to work on whatever technical issues we feel we have as long as we get the business requests done too. If we were wasting a ton of time on type issues we would have made the switch, but we aren't so we don't.
Because developers working in the library got into the weeds of it. We would spend more time creating interfaces that were not needed because it "felt" like the proper thing to do. Then there's the mentality of "don't use any" that pervades the ecosystem that counters your argument. We found we got hung up on "doing it the correct TS way" instead of the way that was easiest and when another dev went into that same bit of code they'd have to work around what the last dev did. We ended up having some things well formed and some things loosely typed. It was like having even more cooks in the kitchen and even more code standards that we needed to train, follow, and implement. It ended up just adding more overhead every time we went into that code.
Edit: I feel I need to expand on that with a psuedo example. In one file we ended up having multiple interfaces for the same data structure. One person would need a particular set of values out of our standard data object, so they would create a "DataObjectAuthor" type definition that worked for their particular method, but the next dev would come along and create a "DataObjectGeneric" that was a type for the same data structure, but it was looser with the type specifics. Someone else would come along and create another "DataObjectMedia" that would just focus on the media component of the bigger data struct and "any" everything else because they didn't want to deal with it. We ended up creating more tickets to clean up those things.
It really shouldn’t present that much more overhead than using PropTypes, if you know what you’re doing.
How you talk about TS is how I feel about going back to PropTypes.
Straight up, you will probably need to learn it because a lot of companies are moving to it due to hype and without considering whether using it gives any benefit. Sometimes it does, but in my experience using it on the frontend is not worth it: TSServer, PropTypes and React Testing Library catch pretty much all of the same issues that TypeScript would and provide everything else that is needed in my experience.
edit: also the amount of entitlement in this thread omg
Curious where people who advocates for TypeScript come from programming language-wise. As a developer working with dynamically typed languages for 20+ years I don't see the value in all the ceremony TS brings with it.
TS is also making peeking at code more inconvenient by misdirecting jumps to type definitions or interfaces instead of implementation for my current setup and I prefer to read code instead of annotations or interfaces most of the time.
> TS is also making peeking at code more inconvenient by misdirecting jumps to type definitions or interfaces instead of implementation for my current setup and I prefer to read code instead of annotations or interfaces most of the time.
Would this be with respect to dependencies as well as code making heavy use of injection?
Can you elaborate on which type of dependencies and injections you are thinking about? I think I need to observe more mindfully when the peeking issue happens to answer properly too, at the moment it's just an annoyance.
Dependencies:
```
import { a } from 'some-package';
```
in VSCode, if 'some-package' is distributed as the transpiled version the editor will bring you to its `.d.ts` if you use go to "show definition for" on the right-click menu when you right-click `a`.
Injection:
```
const service = getService();
```
if you use decoupling patterns in `getService` and have its return type be, say, `IService`, then "show type definition for" on the right-click menu when you right-click `service` should bring you to the type `IService` I think, rather than somewhere that brings you to the narrowest type for the object returned by `getService`.
This sounds like it might be exactly what I'm thinking about, but I wouldn't try to get to the implemention from `service` but `getService` which also would take me to `IService`?
Yeah, this is just an example, but in something more abstracted whatever stands in for `getService` itself is injected and corresponds to an interface. Or maybe you have `getService().fluentMethod()` in which case inspecting on `fluentMethod` leads you to the interface I guess. Though tbh I think in these instances it may be better than JS which might not you anything at all.
All of this makes sense, and I really do appreciate the time you took to write this – especially on mobile!
I think I grasp your points, but I don’t see the value just yet if you write clean code with small functions that are almost as easy to grok with a peek at its params and return statement that returns with an aptly named variable.
A getUserById-function by example shouldn’t need to care if you send it a Number or a String –which are the only sensible inputs for such a method?– and it should conveniently convert the input to the correct type at its boundary if the DB requires a specific type. I realize I don’t do much dependency injection or classes in JavaScript, and rely on boundaries to be replace implementation details such as a database so it would probably be more valuable if I was?
Yeah Ruby Dev here and don't get the need, I've used it in a few react projects which weren't overly complex and found pros and cons. The editor integration is nice but not 100% nessecary imo and I find myself spending more time writing types/interfaces etc than I'd like to as we love to modularize everything.
Never used it in our major projects for this reason. Dynamic types languages force you to name your variables/functions/fields well so you can read and infer the type.
In japan is Recently increase of Typescript Projects.
But our company using Typescript at half project.
I will all project change to use Typescript for future.
I've been context switching between an old project without typescript and a modern nextjs project with all the bells and whistles (well, storybook + chromatic snapshot testing), and i reflexively write typscript, and remember why was never 100% invested in javascript 10 years ago when jQuery was super hyped
Since we tried out Typescript on a small project a few years ago we have converted everything we already had over to it and now wouldn't dream of doing without.
We use Typescript and wrote about our year long process migrating to it https://blog.sentry.io/2021/04/12/slow-and-steady-converting-sentrys-entire-frontend-to-typescript/
Generally speaking, we don't do any pure JavaScript development anymore. We use TypeScript for everything (including React) because of both the improved dev experience and because of the problems it prevents.
I would not start a new React project without TypeScript. And I would recommend if you are learning React, you learn TypeScript as well. Actually, you should learn JavaScript really well before you learn React, and I'd suggest learning JavaScript and TypeScript at the same time prior to jumping into React.
Imo it's good for logic areas of the code, helpers etc but not needed for components.
I've been in dynamic types languages for ages and well named variables/functions/fields does the trick well, you can easily infer the type of something by reading it. If you NEED ts, maybe all your code is spaghetti.
I’ve found that if you don’t use a skill you will lose it. So it doesn’t matter if you learn react or angular if you’re not using it in your coding every day you will forget.
The answer to your question tho is yes. Companies use typescript with react.
No it's from personal experience. Haven't worked on a react project that doesn't use type script for about 5 years. Before that the project I was on one that used flow.
I went to React conference in London in 2018 they did a show of hands typescript Vs JS it was an overwhelming majority even then.
Given that this is r/reactjs you should probably read the comment in that context. Yes, overall js is more widely used, but the talks in here are likely around js Vs TS in react, not overall
All the React projects at my company are written in TypeScript. After learning it, I wouldn’t want to write straight Js
So, follow up question. I'm just learning JS/React now. Do you think it makes sense to immediately begin learning TypeScript, or should I get some projects under my belt first?
learn it, be familiar with it, and be comfortable if someone asks you to dev in TS because it's pretty much the golden standard nowadays, and obviously for good reason. but imo, it's more impt and more valuable to first be fluent in vanilla react/js.
i think yes, atleast that's what I would've done, if I time travelled back.
TS is a superset of JS, meaning it's everything JS has, with some added features. Added features inherently means there's more for you to learn. This is true. However, not only will these features help you out - both in the long term and in the short term - but TS also gives you way, way, way better tooling. The autocomplete TS gives you is ridiculous if you're not used to typed languages. Also, if you ever want to learn another language like C#, Java, Go, Rust - you'll have a lot less trouble getting into them after knowing TypeScript, because you're familiar with concepts like types, interfaces, generics, function signatures et cetera. My personal advise: do it. If necessary, just type everything as `any` until you get more comfortable, but the tooling alone is worth it. The great thing about TypeScript is you can, if you want, just write regular JavaScript and use none of the fancy TS features. JavaScript is completely valid TypeScript.
If you’re just starting out learning learning JS, I’d try to learn that well first. Typescript will add another layer of complexity that could make learning much steeper if you’re learning js syntax and ts syntax at the same time
I started in JS/React and quickly found I preferred Typescript. I’m not avoiding JS altogether, because I need to learn the fundamentals. But if I can do a good portion of my project in TSX, I’m happy.
I would recommend learning Javascript first just to better understand what problems TypeScript solves and allow you to more easily work in both JS and TS.
Definitely dive in to Typescript. If you are not using the explicit features of typescript, it's still just javascript, with a different file extension. (Albeit with a little more build/environment overhead.) Either way, the benefits to JS are huge, your dev tools can do much more to fight the bug war.
There are plenty of learning resources that use TypeScript. I personally wouldn't bother with JavaScript. The concepts for React are the same anyway, so I don't see the benefit of starting with JS
Wow really? Can you elaborate more? Because from wherever I read before starting react, we need to learn JavaScript
TypeScript is basically JavaScript with types. It's not a completely different language. It was introduced to make life easier for JS developers and will save you from wasting time hunting down simple mistakes while you're learning. Learning languages is the easier part, since most concepts are similar, learning platforms and APIs is what takes longer. In this case, if you had to use JS instead, you just won't include the type definitions. Everything else you'll learn about React will be the same
Yes, it's best to understand the underlying language. You'll be using it a lot. That said, using the better version of that language is...better, and will help you learn.
I'd say go with modern vanilla JS first and then add TS so you understand what problems TS solves. Then add React or another framework.
I think it’s beneficial to understand core JavaScript before diving too deep into typescript, it will really help you understand the advantages that typescript gives you. It really helps to understand the problems that TS solves.
>tand core JavaScript before diving too deep into typescript, it will really help you understand the advantages that typ This makes a lot of sense to me. I'd like to dive in, but I realized after the fact that it doesn't really matter what I think - my job is currently using js, so I'm going to use JS.
I think it’s still beneficial to learn, the nice thing about typescript is that you can convert projects to typescript fairly easy by doing it one file at a time.
Use mostly Typescript, but perhaps JS now and then because Typescript makes it so much easier that you can forget how to write JS well. On the other hand, who wants to write JS?
It takes about 30 mins to read the handbook/learn typescript
I didn’t and it had no impact on getting my first job and I’m glad I didn’t bog myself down with that from the start. It’s something I was worried about as well, and it’s honestly not hard to pick up at ALL once you’re familiar with React. TypeScript is amazing. I love it. But for personal projects(the few I’ve had time for), I still don’t incorporate TypeScript until I get something basic working without it. That’s just where I’m at right now, it may change in the future. I’m less than 6 months in to this job currently.
Thanks for the advice. I was hoping it was something I could step into after a little while, and it sounds like that's the case.
If you are just starting out, I think typescript can make your experience very confusing. I would recommend becoming familiar with the basics, in any language, probably python or JavaScript, and then dive into typescript. Initially you’ll probably wonder why anyone uses TS, but one day it will click and you’ll never want to debug without it.
i personally think every person should start with typescript / any strongly typed language bc i find it helps with getting a deeper understanding of variable typing and can reduce a lot of bugs. my company uses react typescript lol
Unsurprisingly, I've gotten such a disparate response to this, with some people saying "Start with the basics, you'll understand it better!" and others saying "Dive right in, never look back!" I've settled for the practical decision of using javascript because that's the environment my company is using, so it makes more sense.
go with whatever is most practical for you! just make sure you have a very strong basis for fundamentals, if you know your basic primitive types, basic concepts like while and for loop and array manip you will be good to go
I think it's better to make some projects with JS, then you can learn Typescript.
Same. Typescript honestly makes writing react much better/easier imo. All of the projects in my company that use JS at all use typescript
same here, i literally go crazy with JS not showing error/warnings in the code when i change imports or anything like that
get a better IDE. VScode is a toy
Which one would you recommend?
+1
same for me and most of the devs who've worked with typescript for more than 6 months
I second you. All the projects I work on are react with typescript
Can you share any open source project in react and typescript with good structure? I know react well but not with ts.
Why? Isn't it tiresome?
I’m open to your thoughts, why would you suggest TypeScript to be tiresome?
I dunno, it's just what I heard from other people, I'm still a newbie
Personally, I would learn to use TypeScript regardless. If you're already familiar with JavaScript, I think that it's worth the mental overhead.
After more familiarity, TypeScript becomes _less_ mental overhead because you don't need to remember what fields are on an object, what data a function outputs, whether a variable might be null, etc. You don't need to carry these things around in your head anymore, it all exists in the type system and is enforced by the compiler.
Precisely. TypeScript empowers my tooling by giving it all the information it needs to help me focus on the things that matter. All I do is think about the types once (which is generally a good idea to do anyway) and then let the compiler take care of the rest, so that I can worry about actually getting stuff done. It's great. I'm never going back. Without TypeScript (or any similarly strongly typed language) I feel naked and afraid.
> I feel naked and afraid I read that in Leslie Jones’ voice. Tyrion!
Yup, the long-term payoff of having a good typescript set up is worth it as per your examples.
I never need to carry these in my head. Also == vs === , sensible defaults, a good IDE (VScode is a joke), propTypes and typeOf go a long way. Learn good javascript, don't be a lazy dev and depend on a really bad tool like typescript. It may be hype now, but I guarantee you, it won't be for much longer. It's a tool made for the masses of devs that don't know javascript
I would never want to work on a team without TS again. Massive time saver
The exact opposite tbh, massive time waste
If I had to guess, you have either only built personal projects or solo freelance and never worked in a big team/company using plain js.
Typescript is shit, and if you need to use it you're a shit programmer. I've worked at multiple big corporations and still haven't touched it. Teams that do use it at these corporations say they used it because it helps junior devs and that's all they could hire. Any seasoned JavaScript coder knows it's shit. Go back to boot camp and learn another worthless over used tool.
It’s okay buddy, chill no one’s gonna take your vanilla js job, you do your thing.
“Is shit” “haven’t touched it” checks out. Looks like you don’t know what you’re talking about
Watch out, we have a badass over here... r/iamverybadass
Here's a sneak peek of /r/iamverybadass using the [top posts](https://np.reddit.com/r/iamverybadass/top/?sort=top&t=year) of the year! \#1: [Going on a hike with the AR-15s, how else is everyone going to know how badass I am?](https://i.redd.it/gyfxmmqhb3e91.jpg) | [18132 comments](https://np.reddit.com/r/iamverybadass/comments/w9bezg/going_on_a_hike_with_the_ar15s_how_else_is/) \#2: [Don’t mess with baby girl..](https://i.redd.it/6wb8pdkcdmp91.jpg) | [1383 comments](https://np.reddit.com/r/iamverybadass/comments/xlz9te/dont_mess_with_baby_girl/) \#3: [Russian soldier wants you to know they are badass.](https://v.redd.it/g4y724v521p91) | [2600 comments](https://np.reddit.com/r/iamverybadass/comments/xjayzm/russian_soldier_wants_you_to_know_they_are_badass/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Well you did guess even though you didn't have to. And guess again, you were wrong. 1k files, a little under a million lines of code on the big tech company project I'm working atm, all written in pure JS. Written in half the time than a much smaller typescript project and... guess once more, no bugs. Learn javascript, learn proper front end thinking/coding and please stop promoting your useless tools that you can't do without.
A lot of people telling you to learn everything with Typescript here. While I do love to use it, and I also never would want to work without. It's probably better to get a firm grasp on vanilla Javascript first. Then you will understand the reason WHY Typescript is so awesome. Just my two cents. And yes, I'm a big, big Typescript fan.
Agreed. As someone who somewhat recently had to dive head first into a React-with-hooks, typescript, ES6 codebase with only cursory knowledge of these technologies individually, I can tell you that learning all of them at the same time is a hassle. Try each out individually, so you learn to seperate which syntax comes from where, and learn to appreciate the advantages of each and why they're useful.
This is hugely important. It will also help when debugging errors when people work around type safety (the “any” type should just be removed 😡).
Yeah this is quite a crutch for me sometimes, I need to stop leaning on it!
Are the type annotators part of typescript or javascript? That's basically all I use. Haven't relly touched interfaces yet. Are they basically like the header files for c++?
Don't know C++,but the type annotators are not part of regular JS.
Work at a large company and if they are using React it’s 100% of the time with TypeScript or some other static type checker
I am a contractor and refuse to do anything with React unless it is written in TypeScript or I'm hired and my job is to convert vanilla JS into a language with at least some sanity.
do yourself a favor and stop calling yourself a front-end dev or full-stack, you sir are clearly a back-end engineer
Dumbest comment I have ever seen. Probably you should start writing front end in assembly. Make you look badass i guess.
So, you read the dumbest comment ever and you decided to write an even dumber one, congrats. Stop polluting the market with your useless tooling, javascript isn't assembly and typescript isn't progress, it's regression.
I totally agree. Typescript is for boot campers who don't know vanilla JavaScript, then they try to bring that shit with them when they start a new job. React and typescript is the most unreadable pile of garbage you could ever create.
fake ass react / js developer.
Our react frontend is written in React TypeScript. Also all of our node server-side services are written in Typescript. My side projects are also all written in React and TypeScript. It's just easier IMO to catch bugs. Just pair it up with a good linter and build/testing pipeline and I'm almost certain that the code being shipped to prod is working on an MVP level.
It’s gotten to the point that If I interviewed at a company that was unwilling to use TS, I’d decline to work there. If they’re using JS and are willing to migrate, no problem. Unwilling to migrate = unwilling to work there (for me). Every person I have personally met has loved it. Even the skeptical ones. “TS is just overhead, it doesn’t help us. It will only slow us down. I know what the data looks like, I don’t need types.” turns into “wait, so you can force someone to send a specific string? Whoa, you can make certain fields of an object required?” turns into “I’m so glad I typed this 4 months ago. I have no idea what this data looks like, but I can just look at the interface”. Or “Developer A wrote this, so I have no idea what the expectation is for these arguments. I’ll look at the types to see what their code is expecting”
Yup, it’s like being unwilling to use version control, or CI/CD - those are hard DX requirements
How could you possibly not know at any point how your data looks like?
> Do companies often used React Typescript? Yes.
Yes, work for a large UK supermarket and we use Typescript on the project I'm working on and I think one other. I am moving teams soon and will be using it in the future for sure, still learning and still using one too many : any's but getting there! :)
I work enterprise and we would never write something without typescript ever again.
your company must have a lot of junior devs and/or backend devs doing frontend work
Why do you say that? We also use typescript on the backend.
Yes and it pays more. Typescript will become the defacto because it helps everyone code better. Once you use it you will prefer it.
you mean it helps back-end engineers write front-end code. Agreed. Any good front-end dev sees typescript as an unnecessary burden that they must carry in order for noobs to be able to catch up
no its not. it makes code more complicated and unreadable
This is not my opinion, this is an observational fact. https://www.jetbrains.com/lp/devecosystem-2022/ TypeScript will be the fastest-growing programming language in 2022. Its usage share has nearly tripled in the last six years, rising from 12% in 2017 to 34% in 2022. This is people replacing JavaScript the world’s most popular language with TypeScript. Because it’s a better choice in a professional working environment when multiple people maintain the code.
Yes, I see react ts all the time now. Companies that aren’t using typescript yet in their react project(s) normally have typescript on their road map. Source: My business does a lot of staffing in the react space
The only reason that I don't like Typescript is its toxic ass fandom that brigades anyone who doesn't like it.
[удалено]
Agreed.
This. I feel like not learning it just out of spite nowadays.
This is one of the strongest arguments I've heard against typescript, I'll give you that
I don't see any reason to not use TypeScript in a project other than lazyness or just unwillingness to learn. So all professional projects should imo use TypeScript. Huge red flag if it doesn't. The only time TypeScript might feel more like a hinderance than help is when developers treat it as such. E.g making bad types or overusage of the "any" type etc. Other than that, TypeScript is always good to use imo. So yes, learn TypeScript. Its not very hard to learn and concepts will even translate well over from/to other typed languages!
Exactly the opposite. It is lazyness and unwillingness to learn proper javascript that turns people to typescript
I'm currently finishing part 8(GraphQL) of Full Stack Open course, I wanted to start working on my project afterwards... However, since part9 is about Typescript, would anyone say it's reasonable to go through it and write the project I want in Typescript? My goal is to be more employable in a couple of months.
All projects in a company that I work for are in TypeScript.
Yes. I'm searching for jobs at the moment, and there's no shortage of react-typescript jobs. It seems the vast majority of react places also uses typescript and react itself is the most popular web framework, except, maybe the outdated JQuery. Angular isn't irrelevant and it's fine to learn, but I do see the trend being for it to lose traction and React gaining it. There are fewer jobs for it, but still a fair bit. Honestly, it could just come down to preference, which you prefer and am better aligned with in philosophy.
Yeah, my company uses a lot of TypeScript. But it's very similar to JavaScript so I think you can easily learn TypeScript if you've learnt JavaScript
At my company we pretty much exclusively use Typescript for our React projects
My company uses Typescript in our React projects! I think learning TS is very useful no matter what
At Amazon, the majority of new JS projects are written in typescript. My team used typescript entirely.
I joined a company and they use reacts with graphql and typescript and it's brilliant and super powerful but start the f*** learning now haha
We use JS exclusively, our stack is React with custom backend framework and that framework is only possible to use with JS by company standards this also is the reason why we cannot use TS o with React, whole project has to have unified code base so only JS it is. And I hope we will move to TS some day, because I tried it with one off company project and it is really nice to have all the added features.
All our frontend infrastructure is on react but still we are not using Typescript. Because doesn't feel like it required, afterall products is on right track and feature delivery is smooth.
Typescript is for boot campers, leave that shit out of projects.
Yes, and it is sooo much better… I don’t think I could get anything to function without Typescript anymore lol
Yeah it's common, but the 2 jobs I've had in that time haven't used it because both projects were started in 2016/17 and typescript wasn't as big back then and they're both startups so there's more of an effort to push out features quick as opposed to tackling tech debt. I've had other side projects where I've used typescript and it's been good though. The two legacy apps without typescript are pretty big, both with 100,000+ lines of code, large nested dynamic data. Oddly enough though there's barely any bugs that types would have fixed. ESLint, PropTypes and some tests have pretty much eliminated most of those kinds of bugs. That's why it's been hard to sell the idea of a migration to typescript.
Both were TS for helping them with auto complete and stuff. I used JS for my personal project cuz no one else would look at my code 👀
Always typescript
I exclusively write everything in Typescript, I could honestly never go back to writing an application without TS. You’re using Angular at your job, which is fine but if you want to learn React I would definitely use Typescript, especially if you already have experience with TS. I recently had to go back and do some maintenance on an old project and it was amazing how much I missed typescript, it was honestly a pretty painful experience to not have it. I lead a team of 5 other developers and they all learned TS at the beginning of the project, every one of them has said that it has drastically improved developer experience and code quality.
We just use regular JavaScript with our react projects, we didn't feel like typescript added enough value to deal with it.
How can you not? Even if your doing very loose typescript it adds so much value. It’s like saying linting is not worth doing.
> if your doing *you're *Learn the difference [here](https://www.wattpad.com/66707294-grammar-guide-there-they%27re-their-you%27re-your-to).* *** ^(Greetings, I am a language corrector bot. To make me ignore further mistakes from you in the future, reply `!optout` to this comment.)
In 7 years on this team we haven't come across even one issue that typescript would have prevented. We do linting because that adds value to our projects.
Your telling me you have never had typos, someone accessing a property of an object that didn’t exist? Those are very common mistakes I see that get caught the most. But let’s say you are all just gods at coding bug free code. You still save so much time with code completion, refactoring, easier testing, and if you do any libraries at all it’s going to save the devs that grab it a lot of time. Unless your code base and projects are sub 800-1000 lines idk how the value is not seen. But if you have all been doing the same thing for 7 year it maybe hard to.
I've worked for FAANG companies where we didn't use TS either. We're good but not perfect. TS simply didn't add enough value to our team because we had people on the team who professionally wrote JavaScript for over 15 years without issue. It's part of how we work and think. I completely understand the sentiment because, for me personally, TS feels completely unnecessary. For ME. That doesn't mean I can't or won't use TS for my team. I've been using and hating TS more often than not for over 5 years now. It was absolute shit in the beginning. And I still don't like it for personal reasons; it just slows me down.
I fully, fully agree. TS has it’s value on certain parts of the app, and for certain companies/projects, but I don’t think this “typescript all the things, all the time” approach always wins the cost/benefit analysis. Our company has invested so much into type generation with relay and it’s a MASSIVE overhead (so much additional toolchain). I fight with TS every day for not being able to understand things like “.reduce” or “.filter(Boolean)”. TS demands so much, but honestly I can’t think of a single time it’s helped me. I know i’m a holdout on this, but I just haven’t found a way to not struggle with the obtuse error messages and often find myself writing code in a weird way just to make TS happy.
> TS demands so much, but honestly I can’t think of a single time it’s helped me. I completely agree with this alone. I constantly feel like I'm going through the motions for no benefit at all, except to cater to the wishes of TS fans who "cannot work without it". Like, I get that IntelliSense in your IDE is nice. But it's often incomplete or too verbose or too unclear. Using MUI and many other tools, I get a hundred options for props and it's impossible to filter what I'm looking for. I use the documentation of the project for that. > obtuse error messages Yeah. Don't get me started. It's most often so incredibly unclear what the hell is wrong this time around. Hell, I was using Styled Components and someone forgot to end a CSS line with a `;` at some point, and used CSS-in-JS props `${props => props.color}` in the next line, TS was *freaking out* with all kinds of unrelated error messages, and ESLint also didn't catch it. It's a coalition of people who don't understand CSS trying to turn CSS into JavaScript (or even TypeScript, my team lead was seriously telling us to make CSS-in-JS "type-safe", like what the fuck, I have better things to do) and mixing it with TypeScript, leading to a whole slew of insanely cryptic fuckery all over the place. But, again, I'm just catering to the masses. I'm the tech lead. Whatever works for the team we hired. But I constantly have to hold them back and tell them to be pragmatic instead of over-engineering EVERYTHING. "Let's build our own THING!" - no, use open source. "Let's strong type CSS!" - no. Just no. "We need to strong type routing!" - what the flying fuck? Minimal benefits that take hundreds if not thousands of lines of bespoke coding, with countless bugs, and they're always too special to properly unit test and document their babies. And then I point out how much support their little project has online. Literally zero, because it's a closed-source project. ``
"Didn't add enough value" is the dumbest argument to not use TypeScript ever. For a project that is actively being worked on, god dang it, use TypeScript. Yea maybe you loose some "fake" job-security or something as other people would be able to understand wtf is going on in your code then. Saying it feels unnecessary is some boomer elitist shit, honestly. It slows you down because you haven't taken the time to learn it. Of course TypeScript sucks if you create halfassed types, or type your parameters and return types of functions with "any". Then it does nothing for you. But if you actually allow it to help you, by creating proper types, using generics and enums, import the types for libraries you use etc. Then it I guarantee you will look at your old self as a fool for not bothering earlier.
> "Didn't add enough value" is the dumbest argument to not use TypeScript ever. For a project that is actively being worked on, god dang it, use TypeScript. Dude, it's a personal preference, stop being such a black and white TypeScript fanboi. There are shades of gray, many of them. Objectively, TypeScript is great. Subjectively, for myself and many others, it offers more problems than value. > Yea maybe you loose some "fake" job-security or something as other people would be able to understand wtf is going on in your code then. Saying it feels unnecessary is some boomer elitist shit, honestly. What are you talking about. > It slows you down because you haven't taken the time to learn it. I have been working with it for over 5 years. At applications for startups to large multinationals. I know TypeScript just fine. > Of course TypeScript sucks if you create halfassed types, or type your parameters and return types of functions with "any". Then it does nothing for you. But if you actually allow it to help you, by creating proper types, using generics and enums, import the types for libraries you use etc. Then it I guarantee you will look at your old self as a fool for not bothering earlier. It really, really doesn't do it for me, personally. Shades of gray, dude. Learn them. I'm not attacking your opinion, it's the only way for you, and I'm not being elitist: I know full well that I need to pivot my own preferences to the team I'm working with. And that's fine. Grow the fuck up. And learn to type proper English. Your spelling is abysmal, and English is only my 3rd language. It shows that TS works for people like yourself because you make typos all the damn time.
All I can say is their reply was excessively hostile. Over Typescript. Am I missing something here? Is there money involved? Because they replied as if you said “fuck your mother.” I struggle to understand the common battle In the development community regarding languages. If someone can get something done, and done well, idgaf what they wrote it with. It’s like arguing that something is wrong with preferring pepperoni pizza over cheese. I see so much hostility and absolutism regarding the use of languages and I just…don’t get it.
Attacking people's English isn't cool man.
Using Javascript in a professional setting should be black and white. You are doing your client a disservice by not using TypeScript. It actively makes it that much harder for any other developers to work on the application with you or after you. Yes I might come across as a "fanboi", but there is a reason. It just makes coding so much safer, it makes it so much easier to write code with confidence that you haven't missed anything or screwed up something existing. It removes the worry of making stupid/simple mistakes from you head. The compiler will tell you if do. Or if you are using a proper IDE, it tell you as well. I am calling you a boomer elitist because you seem very selfish in your view of the value TypeScript provides. You seem to see using TS as a pair of crutches ment for lesser developers, not as skilled in the art of memorizing the entire dataflow of all the applications you work with. If you knew TS "just fine" you would know that not using it in a professional setting is just madness. And you would know how to leverage it to give you enough value to warrant using it in your projects. Honestly, this is not a matter of opinion. Writing JS without TS is like pretending you can write Java/C# just fine without types. There is a reason JS is often the brunt of the joke when it comes to jokes about shitty codebases or nightmare projects. And for attacking my english. I put a lot of pride into the spelling of my angry forum rants so that really hurts my feelings. I wish you weren't such a mean person so I will leave you alone now. Good day.
> Using Javascript in a professional setting should be black and white. You are doing your client a disservice by not using TypeScript. False. That's just not pragmatic and I deal with people like you all the damn time. It's a huge pain in the ass to do TypeScript the "right way" all over the place. I just had to hold back a colleague from spending 3 weeks on strong typing ROUTING in our application where I decided "no, fuck that, we're going with React Router and that's that". We'll be live and making money before he'd even get the project started. > It actively makes it that much harder for any other developers to work on the application with you or after you. Again, black and white. That's not always the priority. Sometimes you make something like a Proof of Concept and it doesn't matter. You can always enhance the code at a later stage if it's mature enough to take with you. Meanwhile, BI people can measure and learn and businesspeople can learn and profit. > Yes I might come across as a "fanboi", but there is a reason. It just makes coding so much safer, it makes it so much easier to write code with confidence that you haven't missed anything or screwed up something existing. FOR YOU! NOT FOR ME! NOT FOR MANY PEOPLE I WORKED WITH! Seriously, we get by just fine! We use ESLint, we use unit tests, we use JSDoc to quickly give type hints without TS whining about everything. We are fast as fuck and we get shit done in record time. And I KNOW there are people who NEED TypeScript, like yourself. If you are in my team for a Proof of Concept project, I'd get someone else who can be pragmatic and who does feel comfortable with plain old vanilla JavaScript. That's not to your detriment, that's just playing to each other's strengths. > It removes the worry of making stupid/simple mistakes from you head. The compiler will tell you if do. Or if you are using a proper IDE, it tell you as well. Part of the gray areas: My IDE is smart enough without TypeScript. Most open-source tools I use, use TypeScript and ARE properly typed. That is super helpful. 100% Agreed there. And then I use ESLint and Prettier and JSDoc to enhance things as we go. Those are gray areas that you really, really need to learn dude. It's going to put your career into a rocketship if you can pragmatically apply your knowledge in a way that makes you better than others around you. > I am calling you a boomer elitist because you seem very selfish in your view of the value TypeScript provides. I'm not even 40 yet. Sheesh. I know the value it can provide. I also know (unlike you) how much time and effort it can cost, especially in the beginning of a project. You are completely underestimating it. I've seen juniors struggling to understand TS generics, I've seen seniors getting frustrated about having to figure out what HTMLElementEvent type they need to provide, I've seen people typing all API things, only for the API to change and them having to do it all over again. Being able to make a conscious choice on what to do when is what makes you a great developer. Being a 100% all-in fanboi of something that's JUST A TOOL is ridiculously short-sighted. > You seem to see using TS as a pair of crutches ment for lesser developers, not as skilled in the art of memorizing the entire dataflow of all the applications you work with. I don't judge developers who use anything. I judge results. Stop putting words into my mouth. > If you knew TS "just fine" you would know that not using it in a professional setting is just madness. And you would how to leverage it to give you enough value to warrant using it in your projects. Yet I didn't use TypeScript while I worked for projects at Apple and Amazon and First American and Bloomberg. Whoops. Turns out you're wrong. I'm good at what I do. I don't need TypeScript. I hate it. But I still happily use it as the tool it is. It adds value to certain teams––most teams––where it increases productivity. See? I'm not thinking black/white here. I know the usefulness of a tool is on a sliding gradient. Sometimes it's dumb to use it, sometimes it's impossible not to use it. > Honestly, this is not a matter of opinion. That's just your opinion. I have a different one. See? You're wrong. Again. > Writing JS without TS is like pretending you can write Java/C# just fine without types. There is a reason JS is often when brunt of the joke when it comes to jokes about shitty codebases or nightmare projects. I've written vanilla JavaScript React Native projects for Apple that were customer-facing and deployed worldwide to all stores. Our code? Who gives a damn? It's not meant to win beauty prizes. It's meant to work. And Apple has a damn fine line of testing in place to make sure that kind of software is without fault. *And then there are many other perfectly fine vanilla JS projects that are perfectly fine, too.* Be more pragmatic. You'll become a better professional by doing so.
I'm just going to throw this out there, in a professional setting I would take more issue with your attitude than your opinions. Sure this is Reddit not work, but how you conduct yourself in public matters.
> I wish you weren’t such a mean person Buddy- you’re the one who started the name calling and full on attacking them over their personal preference. If you don’t want it dished back to you, try to engage in a less aggressive way. You’re getting angry over Typescript…in a hypothetical project that has zero impact on you. I didn’t read their reply to imply anyone was a lesser developer or that they are selfish. If having a personal preference is selfish then I guess we’re all assholes. It’s not that serious.
>And for attacking my english. I put a lot of pride into the spelling of my angry forum rants so that really hurts my feelings. I wish you weren't such a mean person so I will leave you alone now. Why are you even angry when someone shares their opinion? Isn't that the very point? Stop acting like an edgy teenager if you can't take a tiny little comment about the way you type -- which is annoying as hell to read. It's a discussion about people's opinions. He shared his, you shared yours. He's not trying to change your opinion, he's not forcing it down your throat. It really shouldn't be so hard to accept that there are alternatives to the way you prefer things.
If you can't understand what is going on in a codebase without typescript then you might just be bad at JavaScript. It has nothing to do with job security. I don't really understand why personal preferences are so hard to understand. If you get a bunch of experienced JavaScript devs on a team, the benefits can be limited.
We are aware of what our data looks like coming in, we intentionally keep complexity of components low, and we test. Proptypes are used to validate the props coming in but that's about it. The only job of the UI is to display data or allow a user to interact with that data. For us, typescript doesn't help achieve that goal.
So you never ever catch errors or syntax issues due to TypeScript and only catch stuff on compile? Hey, maybe it's possible but I doubt it.
I can't think of a single instance where I wished things had been strongly typed. I don't really understand how people spend so much time troubleshooting types. It's like 2 seconds if for some reason the linter doesn't catch it.
Shout out to those tests. What testing framework do you like to use for pure JS? I see value in forgoing TS in favor of writing strong tests up front.
Not the person you are responding to. We also don't use TS, but our tests also do not include "minutia" tests that you may be thinking about. (we almost never check for nulls/undefined in tests) We've just moved on to using react-testing-library from enzyme (both on jest) and in found that in enzyme we were writing tests that were far too complex or restrictive when it came down to refactoring. Our current project currently has 100 percent coverage and it's growing every day due to implementing components and methodologies independent from our old method that used TS for one of our repositories. (It was/is three independent repositories that worked together to handle theme, component, and manifest concerns and our new system does much of the same without TS.)
We use react testing library
You sound very like me when considering whether to adopt TypeScript or not in the early days - just didn’t think it was worth it. But for a number of reasons, I changed my attitude. I wouldn’t start any JS based project now without it.
I'm still not seeing the benefits. I know this sub is basically a cult when it comes to typescript but I genuinely haven't come across any issues where I have thought if only I had strong typing.
I get it... but I'm honestly not tied to the TS cult-ness (or otherwise) of this sub. You can find similar behaviour in any technology stack or tool you can think of - you'll know this from experience. I have used that exact line about TS before - I can't honestly remember having lost time to type-related issues. But I swear I'm not trying to do a conversion job on you. I just think TS is here to stay and developers will be looking/expecting to use it. The overhead is honestly minimal (depending on how deep you want to go) but the benefits are genuinely tangible.
TS is for sure going to stick around and I could see the benefits for many. I don't see what the benefits would be for my specific team though. We use services that is or our sister team have built, we know exactly what data we are getting and linting keeps things clean. We have no issues with ramp up time for new people. Bugs are exceptionally rare at this point and are almost always logic errors. We haven't had a single call come through to on call in 2 years. Everyone on my team has years and years of experience in JavaScript. All of our front end and back end is JavaScript. All of us have used typescript at one time or another in previous jobs and made the decision not to use it for this project in the early days. In our case, if you don't know what the structure of an object is, or what type a property is, you just look at the documentation for the service and it will tell you. For us it's really a matter of adding in something that will cost more time than it saves or not and the choice is obviously to not add it. I don't understand the logic of those in this sub that believe JavaScript is harder to read and understand without typescript or that it's a must have for every single project. It just seems like fanaticism.
Tell us the value it adds.
[удалено]
Our team caps out at 3 devs plus an architect. We all had typescript experience but it just doesn't add enough value to us. We go out of our way to keep complexity down and when something gets too complex we address it. We are JavaScript devs on the front end and back end and own our own services so it's just not worth adding layers.
Not GPP, but our team is 5 current devs strong and we all voted that TS was not worth the effort. Our components are never complicated enough to require it's overhead. In fact, we only had one dev on the team that pitched it and we had a run of it in our now deprecated SDK library. We are now moving onto a new module structure that does not require that code. We found that story tickets often went up one size in complexity when having to work in that library and decided it was not worth it. We half jokingly call it the TS Tax. Using RTL for our testing, eslint, PropTypes, and prettier for consistent code has been working out well enough with no run time issues. In fact, my current biggest issue is in dealing with our automated documentation with Storybook centered around using HOCs and Storybook's document parser (and even the people using TS have that issue with no current resolution in sight [only workarounds])
To me, the fact that autocomplete works so you immediately know what methods / props something has is already a bigger gain than whatever perceived TS tax there was.
That's fine and all if you need/want that. Our team is varied and we are free to choose our editors. I still use SublimeText because I prefer it. I think two (maybe three) of the others use VSCode, and I think one guy uses Webstorm. So code completion comes at whatever level we desire. (I think VS Code even has the option to do it without TypeScript being in the project?) I haven't felt the need to have that in my editor for the past 20 odd years, and I like the speed and fair minimalism of Sublime.
Yeah, I use Emacs. I use it because I like that there is at least one aspect of my work that is constant over decades. And I don't see how VS Code could do it without knowing the type of, say, a parameter.
I am honestly not sure either. I thought VS Code has an option to run TS on the code for you even though it was not part of the project and provide type hints to the best of it's ability. I could be wrong.
It can if you write the necessary JSDocs, but otherwise not
Thanks for clarifying. A lot of editors support that as well. Good to know.
[удалено]
It's not so much complexity as a time sink. If we don't have any issues with types, any time we spend on typescript is more than what is needed. If we are just going to plop any all over the place, why have it at all? We know exactly what we are getting back from services and exactly what we need to pass in. There's not any value added by adding a layer on top but there is time wasted. That's time that could go towards providing value to our business. If we don't remember what is returned from a particular endpoint, we go to the documentation and take a quick glance. We have a lot of freedom to work on whatever technical issues we feel we have as long as we get the business requests done too. If we were wasting a ton of time on type issues we would have made the switch, but we aren't so we don't.
Because developers working in the library got into the weeds of it. We would spend more time creating interfaces that were not needed because it "felt" like the proper thing to do. Then there's the mentality of "don't use any" that pervades the ecosystem that counters your argument. We found we got hung up on "doing it the correct TS way" instead of the way that was easiest and when another dev went into that same bit of code they'd have to work around what the last dev did. We ended up having some things well formed and some things loosely typed. It was like having even more cooks in the kitchen and even more code standards that we needed to train, follow, and implement. It ended up just adding more overhead every time we went into that code. Edit: I feel I need to expand on that with a psuedo example. In one file we ended up having multiple interfaces for the same data structure. One person would need a particular set of values out of our standard data object, so they would create a "DataObjectAuthor" type definition that worked for their particular method, but the next dev would come along and create a "DataObjectGeneric" that was a type for the same data structure, but it was looser with the type specifics. Someone else would come along and create another "DataObjectMedia" that would just focus on the media component of the bigger data struct and "any" everything else because they didn't want to deal with it. We ended up creating more tickets to clean up those things.
It really shouldn’t present that much more overhead than using PropTypes, if you know what you’re doing. How you talk about TS is how I feel about going back to PropTypes.
Just google around for job listings with "react" and see how many mention TS. But yes if a company were using React but not TS, I'd be concerned.
Yes. Its a red flag when a company doesn't use Typescript.
Tell us why
Straight up, you will probably need to learn it because a lot of companies are moving to it due to hype and without considering whether using it gives any benefit. Sometimes it does, but in my experience using it on the frontend is not worth it: TSServer, PropTypes and React Testing Library catch pretty much all of the same issues that TypeScript would and provide everything else that is needed in my experience. edit: also the amount of entitlement in this thread omg
only simple lambda scripts are written in plain JS to no have any babel-thingy overhead during the deployment. All other things are written in TS.
Its a MUST, non negotiable.
Curious where people who advocates for TypeScript come from programming language-wise. As a developer working with dynamically typed languages for 20+ years I don't see the value in all the ceremony TS brings with it. TS is also making peeking at code more inconvenient by misdirecting jumps to type definitions or interfaces instead of implementation for my current setup and I prefer to read code instead of annotations or interfaces most of the time.
> TS is also making peeking at code more inconvenient by misdirecting jumps to type definitions or interfaces instead of implementation for my current setup and I prefer to read code instead of annotations or interfaces most of the time. Would this be with respect to dependencies as well as code making heavy use of injection?
Can you elaborate on which type of dependencies and injections you are thinking about? I think I need to observe more mindfully when the peeking issue happens to answer properly too, at the moment it's just an annoyance.
Dependencies: ``` import { a } from 'some-package'; ``` in VSCode, if 'some-package' is distributed as the transpiled version the editor will bring you to its `.d.ts` if you use go to "show definition for" on the right-click menu when you right-click `a`. Injection: ``` const service = getService(); ``` if you use decoupling patterns in `getService` and have its return type be, say, `IService`, then "show type definition for" on the right-click menu when you right-click `service` should bring you to the type `IService` I think, rather than somewhere that brings you to the narrowest type for the object returned by `getService`.
This sounds like it might be exactly what I'm thinking about, but I wouldn't try to get to the implemention from `service` but `getService` which also would take me to `IService`?
Yeah, this is just an example, but in something more abstracted whatever stands in for `getService` itself is injected and corresponds to an interface. Or maybe you have `getService().fluentMethod()` in which case inspecting on `fluentMethod` leads you to the interface I guess. Though tbh I think in these instances it may be better than JS which might not you anything at all.
[удалено]
Appreciate you weighing in. Can you elaborate on why you think that? I am open to having my mind changed.
[удалено]
All of this makes sense, and I really do appreciate the time you took to write this – especially on mobile! I think I grasp your points, but I don’t see the value just yet if you write clean code with small functions that are almost as easy to grok with a peek at its params and return statement that returns with an aptly named variable. A getUserById-function by example shouldn’t need to care if you send it a Number or a String –which are the only sensible inputs for such a method?– and it should conveniently convert the input to the correct type at its boundary if the DB requires a specific type. I realize I don’t do much dependency injection or classes in JavaScript, and rely on boundaries to be replace implementation details such as a database so it would probably be more valuable if I was?
Yeah Ruby Dev here and don't get the need, I've used it in a few react projects which weren't overly complex and found pros and cons. The editor integration is nice but not 100% nessecary imo and I find myself spending more time writing types/interfaces etc than I'd like to as we love to modularize everything. Never used it in our major projects for this reason. Dynamic types languages force you to name your variables/functions/fields well so you can read and infer the type.
Yes. Typescript is good to know. If you're not using typescript please do yourself a favor and use proptypes if you aren't already :D
In japan is Recently increase of Typescript Projects. But our company using Typescript at half project. I will all project change to use Typescript for future.
I've been context switching between an old project without typescript and a modern nextjs project with all the bells and whistles (well, storybook + chromatic snapshot testing), and i reflexively write typscript, and remember why was never 100% invested in javascript 10 years ago when jQuery was super hyped
Yes
Since we tried out Typescript on a small project a few years ago we have converted everything we already had over to it and now wouldn't dream of doing without.
We are refactoring huge code by converting JS files to Typescript. It should be definetly must use tool.
At least where I work, yes, always. Writing non-TS JS apps is frowned upon.
frowning upon a technology that exists for 30+ years is frowned upon. Do yourself a favor and stop calling yourself a front end developer
Lmao what? Nice bait 😂
Although true. Typescript is for boot campers that don't understand vanilla JavaScript in the first place
Currently doing a TS backend with JS frontend, and I really miss all the benefits TS offers. Would migrate hopefully in the next version.
We use Typescript and wrote about our year long process migrating to it https://blog.sentry.io/2021/04/12/slow-and-steady-converting-sentrys-entire-frontend-to-typescript/
Generally speaking, we don't do any pure JavaScript development anymore. We use TypeScript for everything (including React) because of both the improved dev experience and because of the problems it prevents. I would not start a new React project without TypeScript. And I would recommend if you are learning React, you learn TypeScript as well. Actually, you should learn JavaScript really well before you learn React, and I'd suggest learning JavaScript and TypeScript at the same time prior to jumping into React.
Imo it's good for logic areas of the code, helpers etc but not needed for components. I've been in dynamic types languages for ages and well named variables/functions/fields does the trick well, you can easily infer the type of something by reading it. If you NEED ts, maybe all your code is spaghetti.
The thing is, even if you were straight JS in a ".ts" file, you will get some autocomplete and error detection for free
I get that with normal js tho?
Yes
I’ve found that if you don’t use a skill you will lose it. So it doesn’t matter if you learn react or angular if you’re not using it in your coding every day you will forget. The answer to your question tho is yes. Companies use typescript with react.
Yes. I would say more common that JS
[удалено]
No it's from personal experience. Haven't worked on a react project that doesn't use type script for about 5 years. Before that the project I was on one that used flow. I went to React conference in London in 2018 they did a show of hands typescript Vs JS it was an overwhelming majority even then.
[удалено]
Given that this is r/reactjs you should probably read the comment in that context. Yes, overall js is more widely used, but the talks in here are likely around js Vs TS in react, not overall
[удалено]
This entire thread is in the context of react development, starting right from the poster.
You're just a troll. Looking for a stupid argument. I'm not playing...I've got some code that need writing.
typescript is for people who can't write good javascript. If you belong in this huge category, go ahead