1. You are applying the ad-hominem fallacy: calling something a name something doesn't remove its value. The reason I didn't point to this label is to avoid people applying the same fallacy and tuning out before considering the merits of the solution.
2. This is the App-style notation. Notice how 'count' is used to indicate quantity not 'int'. You can see all app-style suffixes listed in the article.
3. I'm not the only one to come to these conclusions. From the Wikipedia article you provided:
* Steve McConnell: "... the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately ..."
* Bjarne Stroustrup: "... a technique that can be useful in untyped languages ... [like JS]"
* Joel Spolsky: "... There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong..."
4. this is a sensible, simple, and very light-weight approach to resolve a real problem that is especially pronounced with JS. It has been use for over a decade to manage code and teams and it works very well.
What naming convention do you instead suggest for JS?
I would make the exact same argument but with completely the opposite conclusion. Just use type casting which is self documenting and easily maintained. How can using Typescript be considered somehow less complex?
I think there’s more to it than this but let’s pursue your point for a moment. What you’re not taking into consideration is that de facto standards matter.
What if you invented a language tomorrow called XYZ and it was 20% better than a popular language today?
Would you language eventually take over and become popular? Maybe. After how many years? Who knows. But until that happens far more JS developers are de facto making an investment in learning at least the basics of typescript vs your mechanism.
The practical reality of that is if I start putting together a team to build something it’s much less likely that people will have to take time to learn typescript basics then they will to learn your tool.
Are there times to throw out the old and go with what’s better or simpler? Sure. But that equation is not as simple as X > Y even if that were the case which I’m not convinced it is.
Yes, TS and typecasting can live well together. However, once you combine sensible naming by type and typecasting together, the benefits of TS fade. Then one has to ask: are the remaining benefits worth the expense of running a full TS transpiling infrastructure? In my case, the answer is a definitive 'no'. Typecasting along with Webstorm introspection virtually eliminate may of the issues that TS was designed to solve.
For most of my day-to-day projects, there is no TS transpiling happening at all, .ts/.tsx files are supported by many toolchains in the very same way .jsx files are supported (without any additional overhead over the regular transpiling that is required for any modern JS project). TypeScript is really only active within my editor, not during bundling. This gives me reliable intellisense, code completion, jump-to-definition, rename-symbol, and other IDE features across the whole project.
> Typecasting along with Webstorm introspection virtually eliminate may of the issues that TS was designed to solve.
I personally don't want to stop at /virtually/ eliminating issues that arise due to type errors. I want to /reliably/ eliminate them. And the only way to eliminate type errors is to run a static type checker over the project. (I know the TS type system is not 100% sound, but most definitely better than manual typecasting at runtime).
I do not recommend JSDoc. Instead, typecasting has these advantages:
1. Precise self documenting
2. Much easier to maintain and less verbose (see 1)
3. Requires no external tooling outside of the typecast functions which are hundreds of times less complex than JSDoc checking environments like Closure
4. Adds valuable run-time capabilities that JSDoc does not
> One approach involves using libraries or frameworks such as Flow or TypeScript that require transpiling or otherwise prepocessing the code.
This is a crucial premise of your article, and it's untrue. TypeScript[1] and Flow[2] both support using their static typing without transpiling anything (i.e. the full power of the type systems in plain JS files).
As far as type-cast functions, I've never found that I needed them after switching to TypeScript because the compiler checks that for me.
If you use type guards on all un-typed input (JSON requests/responses, for example), then you don't need type casting at all because you always know your variable's type. That's the whole point of static typing.
This premise is factually true for both TypeScript and Flow. Please explain how you could come to any other conclusion.
I researched this 4 years ago, and since then Typescript has added the `--checkJs` option, but it still you to run a separate process to run the check, which seems to certainly fall under the category of "... otherwise preprocessing the code". And that's an edge case. If you've got TS installed, your almost certainly transpiling. Type guards are typecasting, just renamed to make you sound smarter.
Flow requires a transpiler (https://flow.org/en/docs/install/) and advocates the use of background process. Again, this solidly fits the above premise.
These are enormously complex solution to a problem that can be resolved without transpiling by using 6 small functions and a sensible naming convention. Certainly there are many cases where that makes a lot of sense.
I've developed lots of mission-critical JS that is very widely distributed and there are no type errors despite not using Flow or TS.
test.js:1:20 - error TS2322: Type 'string' is not assignable to type 'number'.
1 Math.round = () => "haha";
~~~~~~
node_modules/typescript/lib/lib.es5.d.ts:708:5
708 round(x: number): number;
~~~~~~~~~~~~~~~~~~~~~~~~~
The expected type comes from the return type of this signature.
Found 1 error.
2. This is the App-style notation. Notice how 'count' is used to indicate quantity not 'int'. You can see all app-style suffixes listed in the article.
3. I'm not the only one to come to these conclusions. From the Wikipedia article you provided:
* Steve McConnell: "... the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately ..."
* Bjarne Stroustrup: "... a technique that can be useful in untyped languages ... [like JS]"
* Joel Spolsky: "... There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong..."
4. this is a sensible, simple, and very light-weight approach to resolve a real problem that is especially pronounced with JS. It has been use for over a decade to manage code and teams and it works very well.
What naming convention do you instead suggest for JS?