We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
之前在好多地方听到Svelte把TS换成了JSDOC,不知怎么慢慢传成了TS要被抛弃了,也没怎么在意。
今日看到光的文章JSDoc真能取代Typescript分析了一下,发现事实并非如此,是由于开发Svelte的过程中,VSCode调试不方便,于是换成了JSDoc,啊这。。。
只能说TS yyds。
不过这两年围绕TS能不能提高开发效率或提高代码健壮性的讨论持续不断,各种说法都有。
个人看来,我还是蛮喜欢TS的,除去维护类型的时候的编写时间,使用的时候很爽。代码格式校验+代码提示这两点,就很舒服。(当然更多的是站在业务层的角度去思考TS的帮助大不大,框架层或者工具层相关的话,开发的较少,这儿就不表达观点了。)
真实情况是,很多React/Vue+TS的项目中,对TS的维护并不好,大部分的类型都靠any支撑。在我看来是一个很不好的喜欢,如果用TS,那么就应该遵守TS的规范,尽力完善代码的格式(不排除有些场景下TS不好用),而不是应该TS+JS混用的形式。
其实还是推荐开发者能够遵守规范,毕竟很多“屎山”代码很大一部分原因是不规范导致的。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
之前在好多地方听到Svelte把TS换成了JSDOC,不知怎么慢慢传成了TS要被抛弃了,也没怎么在意。
今日看到光的文章JSDoc真能取代Typescript分析了一下,发现事实并非如此,是由于开发Svelte的过程中,VSCode调试不方便,于是换成了JSDoc,啊这。。。
只能说TS yyds。
不过这两年围绕TS能不能提高开发效率或提高代码健壮性的讨论持续不断,各种说法都有。
个人看来,我还是蛮喜欢TS的,除去维护类型的时候的编写时间,使用的时候很爽。代码格式校验+代码提示这两点,就很舒服。(当然更多的是站在业务层的角度去思考TS的帮助大不大,框架层或者工具层相关的话,开发的较少,这儿就不表达观点了。)
真实情况是,很多React/Vue+TS的项目中,对TS的维护并不好,大部分的类型都靠any支撑。在我看来是一个很不好的喜欢,如果用TS,那么就应该遵守TS的规范,尽力完善代码的格式(不排除有些场景下TS不好用),而不是应该TS+JS混用的形式。
其实还是推荐开发者能够遵守规范,毕竟很多“屎山”代码很大一部分原因是不规范导致的。
The text was updated successfully, but these errors were encountered: