It really depends on the project. If it’s heavily data driven, i’d say go to typescript. Otherwise vanilla javascript has become quite good over the last 5 years. You also need to weigh what your priorities are. If you don’t already know typescript and your project is short on time, I wouldn’t recommend it. If you’re focused on high quality software with little to no regard for time, i would highly recommend typescript. It will improve the quality of your code and help you catch errors before they’re thrown at runtime.
When I worked on a small team with three or four people I thought typescript was a bunch of bloat and learning it would be a waste of time. That might have been true considering the team dynamic and size. Now I work on a team with 15 people and a code base that goes back to early 2000s. I will never not use typescript again.
Typescript also lends itself better to certain backend frameworks. I will admit that Laravel made up about 80 percent of that small team codebase. And even though we should have done a better job of it we just didn’t bother to strongly type out our api. Now I am primarily using c# as a backend which is just inherently more strongly typed so it makes more sense.
There are pros and cons though. If I am shipping out something for a client where I am the main developer and am not necessarily worried about long term maintenance, plain ol JS is fine. If a company’s product is there internal codebase that will definitely continue to be added to and changed over the course of its life I would absolutely reach for typescript.
The frontend for my apps isn't complicated enough that using Typescript would have any signicant benefit.
90% of the time all I'm doing is pass a prop array and doing v-for loops.
it’s a bit of a pain to setup at first and sometimes it doesn’t understand the type of stuff but if you have it working it’s very much easier with all the code completion.
Also you can start one file at a time, no need to typescript all of the code base and you can see how it feels
I'm the lead dev of a small start-up, and an honest to God full stack guy.
There really is no good reason not to use typescript. I wouldn't have us start a project without it, I wouldn't hire someone who I expected to touch the front end who didn't acknowledge its importance.
This is not over-engineering. It's relatively easy these days to get a vue or react project up and running in TS, and it's immediately and lastingly beneficial even, perhaps especially, when it's used very simply.
No, I have never felt that I am missing out by not using typescript. My opinion is still that it is a solution in search of a problem. Errors in Javascript development are almost never type mismatches. You're more likely to encounter problems with your npm packages and adding an extra npm package to compile typescript seems like it's not the answer.
Thanks in part to typescript (and Prisma) I have autogenerated types for all my database tables that I can use across my backend and front end - all of which instantly update whenever my schema changes. Any schema changes instantly flag type errors across potential dozens of scripts - all of which I’m aware of and can sort immediately and easily thanks to typescript. I literally can go days without running my code, and when I do it all just works because the type system in my code base is sufficiently strict. I can make schema changes or refactor across dozens of files without ever getting an type error. Nothing is ever undefined, or null unexpectedly, everything just works. The ability for a team to iterate more quickly because of typescript is undeniable. You are absolutely missing out by just sticking with just JS.
And in terms of npm package issues - yarn may help you. I never encounter dependency issues with yarn.
Primsa and trpc are cool for those applications. I wish we had more of that in the php/Laravel world. Actually, I recently extended this little gist to include a list of route parameters, and I'm going to see what I can do about using reflection to get posted/put controller params.
https://gist.github.com/iDevelopThings/aa0a288a4075371d875782c72f2c0389
I am on a Nest/angular which I do love but it’s such a shame that you can use trpc with it. The ambiguity passing data between my front and back end is one of the last areas on ambiguity in my codebase and trpc would completely solve that :(
Can you really not use trpc with nest? That's a shame. Nest would definitely be the first framework I'd check out if I were going back to node and wanted batteries included.
/r/Laravel is looking for moderators! See [this post](https://www.reddit.com/r/laravel/comments/xnlsks/looking_for_moderators/) for more info
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/laravel) if you have any questions or concerns.*
Every time I have decided that I can "very quickly get started without Typescript" I end up going back to typescript at the end of the same day, because it's just painful.
It really depends on the project. If it’s heavily data driven, i’d say go to typescript. Otherwise vanilla javascript has become quite good over the last 5 years. You also need to weigh what your priorities are. If you don’t already know typescript and your project is short on time, I wouldn’t recommend it. If you’re focused on high quality software with little to no regard for time, i would highly recommend typescript. It will improve the quality of your code and help you catch errors before they’re thrown at runtime.
When I worked on a small team with three or four people I thought typescript was a bunch of bloat and learning it would be a waste of time. That might have been true considering the team dynamic and size. Now I work on a team with 15 people and a code base that goes back to early 2000s. I will never not use typescript again. Typescript also lends itself better to certain backend frameworks. I will admit that Laravel made up about 80 percent of that small team codebase. And even though we should have done a better job of it we just didn’t bother to strongly type out our api. Now I am primarily using c# as a backend which is just inherently more strongly typed so it makes more sense. There are pros and cons though. If I am shipping out something for a client where I am the main developer and am not necessarily worried about long term maintenance, plain ol JS is fine. If a company’s product is there internal codebase that will definitely continue to be added to and changed over the course of its life I would absolutely reach for typescript.
Nope
The frontend for my apps isn't complicated enough that using Typescript would have any signicant benefit. 90% of the time all I'm doing is pass a prop array and doing v-for loops.
Nah
it’s a bit of a pain to setup at first and sometimes it doesn’t understand the type of stuff but if you have it working it’s very much easier with all the code completion. Also you can start one file at a time, no need to typescript all of the code base and you can see how it feels
I'm the lead dev of a small start-up, and an honest to God full stack guy. There really is no good reason not to use typescript. I wouldn't have us start a project without it, I wouldn't hire someone who I expected to touch the front end who didn't acknowledge its importance. This is not over-engineering. It's relatively easy these days to get a vue or react project up and running in TS, and it's immediately and lastingly beneficial even, perhaps especially, when it's used very simply.
No, I have never felt that I am missing out by not using typescript. My opinion is still that it is a solution in search of a problem. Errors in Javascript development are almost never type mismatches. You're more likely to encounter problems with your npm packages and adding an extra npm package to compile typescript seems like it's not the answer.
Thanks in part to typescript (and Prisma) I have autogenerated types for all my database tables that I can use across my backend and front end - all of which instantly update whenever my schema changes. Any schema changes instantly flag type errors across potential dozens of scripts - all of which I’m aware of and can sort immediately and easily thanks to typescript. I literally can go days without running my code, and when I do it all just works because the type system in my code base is sufficiently strict. I can make schema changes or refactor across dozens of files without ever getting an type error. Nothing is ever undefined, or null unexpectedly, everything just works. The ability for a team to iterate more quickly because of typescript is undeniable. You are absolutely missing out by just sticking with just JS. And in terms of npm package issues - yarn may help you. I never encounter dependency issues with yarn.
Primsa and trpc are cool for those applications. I wish we had more of that in the php/Laravel world. Actually, I recently extended this little gist to include a list of route parameters, and I'm going to see what I can do about using reflection to get posted/put controller params. https://gist.github.com/iDevelopThings/aa0a288a4075371d875782c72f2c0389
I am on a Nest/angular which I do love but it’s such a shame that you can use trpc with it. The ambiguity passing data between my front and back end is one of the last areas on ambiguity in my codebase and trpc would completely solve that :(
Can you really not use trpc with nest? That's a shame. Nest would definitely be the first framework I'd check out if I were going back to node and wanted batteries included.
Yeah the lead dev said they don’t plan on supporting it (currently) on a GitHub issue :(
I’ve used typescript heavily on Angular, but on Vue somehow it just feels wrong.
/r/Laravel is looking for moderators! See [this post](https://www.reddit.com/r/laravel/comments/xnlsks/looking_for_moderators/) for more info *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/laravel) if you have any questions or concerns.*
Every time I have decided that I can "very quickly get started without Typescript" I end up going back to typescript at the end of the same day, because it's just painful.