Regarding Typescript, I think you're a little off the mark. For me, I think Typescript is a tool that helps me wrap my head around just what exactly is going through my JS code. There's so many various shapes objects can take, and it actually speeds up my development if I can know up front what the data going through my code will look like.
More generally, the tools I use need to match how I'm thinking through a problem. Maybe your brain is more JS-oriented, and mine is more Typescript-oriented? I don't know. I just know that TS can help correct this impedance mismatch I have between my brain and JS, and through that lens, I think it's useful even for a brand new prototype project, not just rock solid production-level code. It helps me stay organized and think through problems.
It's also worth mentioning that typing with Typescript can be incremental, that you don't have to type absolutely everything up front. So you can add types where it makes sense, where the pain points are in your code. The example that immediately comes to mind is date/time parsing and formatting -- I mean, how many different formats can a date/time go through?
Fair comment. If Typescript helps you keep things organized in your head and move faster, then great. You should absolutely use what works for you. I prefer the less rigid JS because it appeals to me much like NoSQL feels better to me than SQL.
I will say that in spite of my JS preference if I were working on a bigger codebase with more contributors and more at stake, I'd go with TS.
Yeah, I feel like all else being equal, whatever works for you personally is the "right solution". If something makes you more expressive, that's a meaningful benefit that often gets overlooked.
But yeah, on larger teams, I think the benefit is clearly there. Which gets me thinking...
How can languages have more opt-in features that devs can use to be more comfortable in their flavor of the language? Without turning into a heaping mess, that is. Perl comes to mind -- great for one-offs, absolutely terrible for anything sustainable.
I was thinking more about built-in syntax and language features. For example, I might opt to use a syntax that enables type declarations. Or if I'm writing certain kinds of modules, I might use a feature that loads any imports into a global namespace.
I suppose you can add these by extending syntax to be general enough, like "import *" in JS, but that makes the base language larger, makes implementation harder, and slows execution speeds if you have a bunch of stuff loaded you're not using. I'd be more on the side of choosing which features I want to enable at compile time and using a pared-down version of the language at runtime.
Regarding Typescript, I think you're a little off the mark. For me, I think Typescript is a tool that helps me wrap my head around just what exactly is going through my JS code. There's so many various shapes objects can take, and it actually speeds up my development if I can know up front what the data going through my code will look like.
More generally, the tools I use need to match how I'm thinking through a problem. Maybe your brain is more JS-oriented, and mine is more Typescript-oriented? I don't know. I just know that TS can help correct this impedance mismatch I have between my brain and JS, and through that lens, I think it's useful even for a brand new prototype project, not just rock solid production-level code. It helps me stay organized and think through problems.
It's also worth mentioning that typing with Typescript can be incremental, that you don't have to type absolutely everything up front. So you can add types where it makes sense, where the pain points are in your code. The example that immediately comes to mind is date/time parsing and formatting -- I mean, how many different formats can a date/time go through?
Fair comment. If Typescript helps you keep things organized in your head and move faster, then great. You should absolutely use what works for you. I prefer the less rigid JS because it appeals to me much like NoSQL feels better to me than SQL.
I will say that in spite of my JS preference if I were working on a bigger codebase with more contributors and more at stake, I'd go with TS.
Yeah, I feel like all else being equal, whatever works for you personally is the "right solution". If something makes you more expressive, that's a meaningful benefit that often gets overlooked.
But yeah, on larger teams, I think the benefit is clearly there. Which gets me thinking...
How can languages have more opt-in features that devs can use to be more comfortable in their flavor of the language? Without turning into a heaping mess, that is. Perl comes to mind -- great for one-offs, absolutely terrible for anything sustainable.
When you say opt-in features, are you talking about adding libraries or modules like npm? Or are you referring to something else?
I was thinking more about built-in syntax and language features. For example, I might opt to use a syntax that enables type declarations. Or if I'm writing certain kinds of modules, I might use a feature that loads any imports into a global namespace.
I suppose you can add these by extending syntax to be general enough, like "import *" in JS, but that makes the base language larger, makes implementation harder, and slows execution speeds if you have a bunch of stuff loaded you're not using. I'd be more on the side of choosing which features I want to enable at compile time and using a pared-down version of the language at runtime.