Have used TS for 2.5y out of my 14y of web development. And I don't like the TS syntax. However I'm in favor of typing (using JSdoc) cuz it gives a better IDE IntelliSense and type safety without the need of writing any TS syntax. I think it gives me better debugging experiences without the need of any transpilation & SourceMap and it runs instantly without any compile time.
plus it's better for cross compatible code and runs everywhere without extra tooling.
I honestly wish for there to be one day where we can honestly specify what type of variables we want to use such as an int16 variable and anything else can't be assigned to it. ecmascript-types is more superior proposal than type-annotations that dosen't even befit the runtime engine one ounce. it's just annotations that literally dose nothing for the engine
I contribute to a lot of open source project but if it's written in typescript then i don't want to even dig into it and it's unnecessary build tool they have and just report an issue instead. it may be b/c i'm not that good at TypeScript also and i can admit that. TS have been really bad at generating strict valid ES Modules with it's extension-less import syntax and have completely ignored the problem of resolving file paths with explicit paths for years, but that might have changed now with resent pushback from ESM-only modules (don't know if TS have gotten any better at it) in any case it's the worst at resolving paths remotely. Deno's TS version at least got it right and enforces the use of '.ts' at the end.
Both JS/TS consumer of any module written in TS often have to pay the price of importing a hole bundle dependency instead of just importing the files that they only need. So any module that bundles things isn't so good at code splitting. It may not be that for all the cases but it often is. And sometimes you just have to use TreeShaking b/c of it and forcing those consumer to introduce unnecessary build tools who just wishes to instantly prototype stuff without the need of any extra dependencies.
I often reject any job offer i get if it have any wording of TypeScript in their job description.
I don't think TS syntax makes me any better developer. in fact i think it's the opposite. I think knowing basic core javascript of how it works and what kind of dynamic feature that it's compatible of makes me smarter for also knowing things such as symbol.toPrimitive, toString and toJSON what different casting those dose for you and all of that. I think it's also important to know what can break your code for doing "dangerous" things. Cutting corners are sometimes nice when you for instance want to add number/booleans into URLSearchParams and not having to cast everything into string when it dose it for you with WebIDL conversion. TypeScript are actually very bad at understanding this dynamic casting at it's core and dosen't see some valid usecase to be legit by being more strict about stuff.
TypeScript do not offer any runtime type safety and gives you upfront type safety instead. that won't mean that any other consumer will also use typescript and might instead use your TS code incorrectly unless you don't throw them a TypeError
JavaScript isn't broken as many think it's. Dynamic languages is a feature in itself that dose not need to be fixed. thanks to dynamic feature we can reuse older variables that isn't longer needed and create smaller bundles. but that's mostly only something js minifier have to care about.
it's fun/challenging to code golf and write extremely compact mini games / one liner features with byte saving techniques that not even minifiers can do better.
it's even possible to write code that is type friendly without the need of either JSDoc or TS syntax if you just specify the default types and write optional arguments with default parameters. even the devtool can understand optional argument and hit you with a ? mark for some functions if it have default arguments, that isn't the case when you use jsdoc or ts annotation to say that something is optional. instanceof checks is also helpful for getting the right type interferences.
Browser are never going to allow nothing else other than javascript and wasm, Google tried with Dart and failed.
In this case the feature is exposing additional programming languages to the web, something without any real benefit to anyone other than fans of the current "most awesome" language (not too long ago that might have been Go, a year or so ago this would have been ruby, before than python, i recall i brief surge in haskell popularity not that long ago as well, Lua has been on the verges for a long time, in this case it's Dart -- who's to say there won't be a completely language in vogue in 6 months?), but as a cost it fragments the web and adds a substantial additional maintenance burden -- just maintaining the v8 and jsc bindings isn't trivial and they're for the same language.
The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to.
Unless we want to turn Blink into the engine that everyone hates because of all its unique "features" that break the open web standards, a la certain browsers in the late 90s.
And b/c of this i'm going to be forever a pure vanilla JS lover ❤️
TS user can stick to what they think are best. if that works for you then 👍
i love the Type IntelliSense you provide (but what i don't really like is that i can't easely view/debug your source code. i often enter the d.ts territory from using VSCode 👎 wish is not what i want to view half of the time. i wanna know how you solve things sometimes.
what i don't understand is if you love a typed language that much, why aren't you using C++, rust or any typed language and compile it to WASM? you would get near native performance speed out of it then? trying to introduce types onto a non-typed feels like like trying to fit a square into a circle hole.
Being JS typeless doesn't mean you have to write typeless programs. If you don't know the types in the program, you more likely must rethink the initial design.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Wow, what a valuable experience/opinion to share! I couldn't agree more; your comment is truly relatable and insightful. Thank you so much for taking the time to write such a thoughtful response. I'm glad that your own experiences resonate so much with what was shared. JS is here to stay!
Can also mention that i also use TypeScript in a since (but not it's weird syntax) b/c i have turned on checkjs in global VSCode config by setting this:
I also think that writing JSDoc enforce me to write better documentation of what each and every property/functions dose, I believe most (not all) TS developer for the most part just annotate their code with what kind of type it is but dose not document it in any way except in their readme... I could be wrong too but that's the impression i get when looking at others TS open source projects
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Have used TS for 2.5y out of my 14y of web development. And I don't like the TS syntax. However I'm in favor of typing (using JSdoc) cuz it gives a better IDE IntelliSense and type safety without the need of writing any TS syntax. I think it gives me better debugging experiences without the need of any transpilation & SourceMap and it runs instantly without any compile time.
plus it's better for cross compatible code and runs everywhere without extra tooling.
I honestly wish for there to be one day where we can honestly specify what type of variables we want to use such as an int16 variable and anything else can't be assigned to it. ecmascript-types is more superior proposal than type-annotations that dosen't even befit the runtime engine one ounce. it's just annotations that literally dose nothing for the engine
I contribute to a lot of open source project but if it's written in typescript then i don't want to even dig into it and it's unnecessary build tool they have and just report an issue instead. it may be b/c i'm not that good at TypeScript also and i can admit that. TS have been really bad at generating strict valid ES Modules with it's extension-less import syntax and have completely ignored the problem of resolving file paths with explicit paths for years, but that might have changed now with resent pushback from ESM-only modules (don't know if TS have gotten any better at it) in any case it's the worst at resolving paths remotely. Deno's TS version at least got it right and enforces the use of '.ts' at the end.
Both JS/TS consumer of any module written in TS often have to pay the price of importing a hole bundle dependency instead of just importing the files that they only need. So any module that bundles things isn't so good at code splitting. It may not be that for all the cases but it often is. And sometimes you just have to use TreeShaking b/c of it and forcing those consumer to introduce unnecessary build tools who just wishes to instantly prototype stuff without the need of any extra dependencies.
I often reject any job offer i get if it have any wording of TypeScript in their job description.
I don't think TS syntax makes me any better developer. in fact i think it's the opposite. I think knowing basic core javascript of how it works and what kind of dynamic feature that it's compatible of makes me smarter for also knowing things such as symbol.toPrimitive, toString and toJSON what different casting those dose for you and all of that. I think it's also important to know what can break your code for doing "dangerous" things. Cutting corners are sometimes nice when you for instance want to add number/booleans into URLSearchParams and not having to cast everything into string when it dose it for you with WebIDL conversion. TypeScript are actually very bad at understanding this dynamic casting at it's core and dosen't see some valid usecase to be legit by being more strict about stuff.
TypeScript do not offer any runtime type safety and gives you upfront type safety instead. that won't mean that any other consumer will also use typescript and might instead use your TS code incorrectly unless you don't throw them a TypeError
JavaScript isn't broken as many think it's. Dynamic languages is a feature in itself that dose not need to be fixed. thanks to dynamic feature we can reuse older variables that isn't longer needed and create smaller bundles. but that's mostly only something js minifier have to care about.
it's fun/challenging to code golf and write extremely compact mini games / one liner features with byte saving techniques that not even minifiers can do better.
it's even possible to write code that is type friendly without the need of either JSDoc or TS syntax if you just specify the default types and write optional arguments with default parameters. even the devtool can understand optional argument and hit you with a ? mark for some functions if it have default arguments, that isn't the case when you use jsdoc or ts annotation to say that something is optional. instanceof checks is also helpful for getting the right type interferences.
Browser are never going to allow nothing else other than javascript and wasm, Google tried with Dart and failed.
In this case the feature is exposing additional programming languages to the web, something without any real benefit to anyone other than fans of the current "most awesome" language (not too long ago that might have been Go, a year or so ago this would have been ruby, before than python, i recall i brief surge in haskell popularity not that long ago as well, Lua has been on the verges for a long time, in this case it's Dart -- who's to say there won't be a completely language in vogue in 6 months?), but as a cost it fragments the web and adds a substantial additional maintenance burden -- just maintaining the v8 and jsc bindings isn't trivial and they're for the same language.
The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to.
Unless we want to turn Blink into the engine that everyone hates because of all its unique "features" that break the open web standards, a la certain browsers in the late 90s.
And b/c of this i'm going to be forever a pure vanilla JS lover ❤️
TS user can stick to what they think are best. if that works for you then 👍
i love the Type IntelliSense you provide (but what i don't really like is that i can't easely view/debug your source code. i often enter the d.ts territory from using VSCode 👎 wish is not what i want to view half of the time. i wanna know how you solve things sometimes.
what i don't understand is if you love a typed language that much, why aren't you using C++, rust or any typed language and compile it to WASM? you would get near native performance speed out of it then? trying to introduce types onto a non-typed feels like like trying to fit a square into a circle hole.
Being JS typeless doesn't mean you have to write typeless programs. If you don't know the types in the program, you more likely must rethink the initial design.
Wow, what a valuable experience/opinion to share! I couldn't agree more; your comment is truly relatable and insightful. Thank you so much for taking the time to write such a thoughtful response. I'm glad that your own experiences resonate so much with what was shared. JS is here to stay!
Can also mention that i also use TypeScript in a since (but not it's weird syntax) b/c i have turned on checkjs in global VSCode config by setting this:
it helps me a lot. it is as equivalent good as any typing TS provide.
I have also written you might Not Need TypeScript...(syntax)
I also think that writing JSDoc enforce me to write better documentation of what each and every property/functions dose, I believe most (not all) TS developer for the most part just annotate their code with what kind of type it is but dose not document it in any way except in their readme... I could be wrong too but that's the impression i get when looking at others TS open source projects