这是一个创建于 352 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
crazyTanuki 352 天前  1
国内这个技术都找不到工作...
|
 |
2
dengqing 352 天前 via iPhone
早就放弃了吧
|
 |
3
chenluo0429 352 天前 via Android
三月份的文章，你这网速有点慢啊
|
 |
4
wangtian2020 352 天前 2
只要有正确的编辑器提示，它用的是 jsdoc 还是 typescript 根本无所谓。我用 typescript 也就是馋它的类型提示，动态类型里搞类型安全本来就是脱裤子放屁，java 类型安全想必从来不出错吧？
|
 |
5
weijancc 352 天前 2
Svelte 作为底层框架不用 ts 很正确, ts 编译后的 js 不可控, 会对性能有损耗
|
 |
6
s5s5 352 天前
这个文章分析过了 --->>> JSDoc 真能取代 TypeScript ？ https://juejin.cn/post/7292437487011856394
|
 |
7
QlanQ 352 天前 1
感觉 ts 有点跑偏了，明明只是为了 编辑器有提示，再加上基础的 类型检查，结果要换一种语言，确实不太合适，还不如类似 PHP ，在后续的更新版本加上 返回值，参数类型定义的东西，一步一步来，而不是换一种语言做 转译
|
 |
9
FreshOldMan 352 天前 1
@wangtian2020 #4 这和出错不出错没关系，类型是让项目在多人维护，长期维护的情况下，能更方便的迭代下去，你说你要是做外包的，项目一做一扔，确实 js 可以
|
 |
10
draco95 352 天前 3
不怎么看，说明 ts 已经是项目标配了，毕竟以前是哪个项目用上了 ts 才会上新闻，现在是哪个项目不用 ts 才能上新闻
|
 |
11
dufu1991 352 天前 1
我的组件库 https://github.com/any-tdf/stdf 前几天按照 JSDoc 规则增加了 Props 的注释，写组件参数的时候会有类型提示，可选项也直接提示出备选项，开启 checkJs 或者 TypeScript 也会有类型校验。
感兴趣的可以使用 pnpm create stdf 创建个工程试试。 代码反正都要写注释，这样既省略了 TypeScript 编译开销，又有类型校验和提示，我觉得能满足大多数场景了。 |
 |
12
emSaVya 352 天前 1
@wangtian2020 类型安全强调的是编译器检查 跟出不出错有什么关系？
|
 |
13
myvin OP @chenluo0429 村里通网无所谓，只是看这个问题哈
|
 |
16
zed1018 352 天前
娱乐圈就是这样，它好的时候哪里都好完美无瑕，它不好的时候就罪大恶极吃枣药丸
|
 |
18
visper 352 天前
我觉得使用 typescript 最简单的类型标注一下就能得到 80%的好处了。但是想得到后面那一点点，反而走向了极端把写类型的复杂度增加了几倍。一个好几行代码复杂的类型比看一百行程序逻辑还复杂。动不动类型标注比代码还要多好多。
|
 |
19
cwliang 352 天前
前端框架太多了，svelte 没啥存在感
 |
 |
20
minglanyu 352 天前
说实话大多数 CRUD 的业务场景，还不需要通过 svelte 这种去运行时框架来优化性能。
大多数场景对于 react 和 vue 这种自带 runtime 的框架来说，带不带 runtime 其实差别不大，况且框架 react 和 vue 的生态相对更加健全。 拉回正题。ts 这个东西，当作工具使用吧，不要被工具太过于束缚了。 |
 |
21
Jaeger 352 天前
Svelte 这么好用，为啥国内没啥人用呢？
|
 |
22
Orangeee 352 天前
@Jaeger 生态和其他成熟框架比太一般，Vue 能干并且能干好的事，一般开发者没理由选 Svelte ，Vue 对大部分业务场景有开源案例支持，毕竟公司需要的是高效稳定开发迭代产品，不是怎么优雅编码。
|
 |
24
justfindu 352 天前
@crazyTanuki #1 别急 再等等, 马上鸿蒙 APP 全都是 TS. 哈哈哈哈
|
 |
25
xuhai951753 352 天前
戏太多
|
 |
26
Leviathann 352 天前
who use it?
不过话说回来 react 也不是 ts 写的，而是 ts 主动去适配 |
 |
27
huruihhh 352 天前 1
😓 能不能别用缩写了。wyz 是什么意思
|
 |
28
xieren58 351 天前 2
早换 solidjs 了...
|
 |
29
sx931210 351 天前
前端事太多
|
 |
31
realJamespond 351 天前
不如 solidjs ，和 react 写法相似，至少容易让人接受
|
 |
34
a132811 351 天前 1
只是作者的个人喜好。
并不是真的完全放弃，依然要用 SvelteKit 生成 types 。 上次看到新闻还是大约半年前，现在官方的源码依然需要 tsconfig.json 。 工具而已，不要上升到派系之争。 但是，当需要类型的场合，依然是 ts 最强大。jsdoc 不能替代 ts ，它本身类型推导能力很有限。 我觉得 ts 的问题最大的问题不是它复杂，而是许多基础的 npm 包像 jest 到现在对 ts 支持都不完善，从上层到到低层的改造成本很大，有的时候不用 ts 还更简单。deno 下的 ts 体验倒很好，可惜生态不好 |
 |
35
zhwithsweet 351 天前
无所谓，反正前端没岗位，爱用啥用啥。
|
|
36
crazyTanuki 351 天前
@justfindu 除非政策出一波补贴,类似新能源那种,否则不太看好
|
 |
38
pengdahan4 351 天前
人家是因为团队都是高质量开发技术人才，可以不需要 ts 来约束，替换 jsDoc 就可以保证项目的健壮性。国内的公司开发水平参差不齐，ts 约束可以延长屎山形成的时间
|
 |
39
libook 351 天前 1
不影响大家选择适合自己的方案，只是对于同样在使用 TS 的过程中遇到新痛点的人来说，不用可能也是一种可以尝试的选择。
JSDoc/ESDoc 用过很长时间，如果团队里有成熟的编码规范和可靠的实施的话，结合代码分析能力强的 IDE ，是完全可以替代 TS 的，这也是为什么很长时间里我对 TS 不感冒。 我举个例子，并不是所有用到 JS 的场景都是在浏览器和 Node.js 上跑的，一些场景下 JS 被用于作为一些其他软件的嵌入语言（类似于 Lua ），甚至有些需要在专用的界面输入 JS 脚本，此时 TS 的编译层可能就会成为使用效率的短板，但利用注释的 JSDoc/ESDoc 不会，因为它们本来就可以被标准的 JS 解释器/引擎正确处理。 另外就是 JS 本身是个极其灵活的语言，所以它对开发者要求很高，缺乏经验的开发者会有较大概率写出有缺陷的代码，而 TS 就是通过限制语言的灵活性，来帮助开发者降低心智负担，从而提升了工业生产的效率。但万一开发者是个精通 JS 的大佬级人物，将 JS 运用到出神入化了，这时候没准灵活性反而成了高优先级需求。就像一些 C 语言大佬的程序，代码难懂，但也确实比其他现有方案能更好满足功能需求。 不过说能替代也是说的一部分场景下的，总有些场景下，结合团队和项目情况来综合衡量，TS 可能更适合，这也是 TS 存在并被广泛使用的原因。 TS 要想取代 JS ，大概率只有普及 TS 原生引擎这一条路可以走；只要没法取代 JS ，就一定只能苟在 JS 技术栈的子集里。换言之本来就是一个技术栈，绝大多数人是两种都会/用/容易上手的，也没必要单立派别啥的。 |
 |
40
journalistFromHK 351 天前 via iPhone
ts 有违 js 天性 人人得而诛之
|
 |
41
7inFen 351 天前
ts 不是 js 超集这么简单，应该把 ts 当成一门新语言看待
|
 |
42
evan1024 351 天前
底层使用也不影响,反正用 ts 不还是要转 js, 技术纯粹也是一个节省精力的选择
|
 |
43
johnnyNg 351 天前
1 、ts 类型和语言融为一体，写起来更符合直觉
2 、ts 类型能复用，jsdoc 咋复用 3 、编译问题，你现在用 js 写不是也要编译到低版本 4 、ts 确实有一些问题，但是希望他能越来越好，而不是淘汰掉 |
Select Language