Subilan

@makaflow Thanks

@makaflow 是啊，当时就想不通为什么苹果的品控能让我中标。我中间有段时间用过 Al Dente ，那段时间电池寿命也一直在掉。现在已经摆烂了，电池坏了就换吧。（顺带在这里问一下大概是多少钱？）

你三年 77%。我 M2 Pro 一年不到 83%，还没提示维修。曾经有那么几天每天去看电池健康度都在掉。
目前大概能轻度使用 6 小时顶天。

有趣极了。

要简单易用的语言学来给自己做后端的话，不考虑性能 Python 确实是一个选择，但是还是更加推荐 Node （ JS 也不难只是乱），这两个语言的语法都不严格。C#、Java 乃至 Go 之类的也不是不能考虑，因为只要没有复杂的场景，照着文档调库也能写出个像模像样的后端出来。
具体看你个人的使用经验能否和目标语言契合从而能够快速学习了。

低代码（不是表单的那种，之前在这个网站上也看到有人把这个称作低代码）本质上是在把需求量化、模式化，这些需要足够和足量的调研和验证。

但是广泛层面的需求终究是不规则的，低代码平台所解决的也只能是一个个需求组合。许多行业都有那么几套大部分人都在沿用的方案和逻辑，所以低代码平台只通过对这些方案的实现，就可以满足大部分客户的需求。

只是从开发的角度来看，低代码没有那么理想化那么完美。

我个人认为 TypeScript 还是像一部分人宣称的那样，是为了大项目而存在的，而对于一些小型的项目来说可能又成了一种负担。但是在这里对于大小的区分，我认为这不仅和代码量有关，还和一个团队的沟通模式，乃至个人习惯有关。

像 Solo 或者几个人组成的开发团体，沟通的模式相当具有多样性，因此 TS 这种“与代码高度契合的沟通”不一定能够成为一个很好的选择。这中间甚至还可能有一些微妙的个人因素，比如说有些人就喜欢 TS 这种相比于 JS 高度模式化的代码，有些人就恰恰相反。

从实际角度来看，TS （相比于 JS 多）起到的作用大概是把一些设计代码化，以及借助 tsc 达成所谓的 type safe 。但是当这群人不需要也能做好这一切时，那即使有那么一点可能性会犯一些错误，但是不需要就是不需要。

所以我个人感觉还是按照具体需求来，没有“更适合”一说。目前而言我做的一些简单的小脚本是用纯 JS 写，时间比较紧迫的项目也是用 JS 写，而一些慢节奏、投入大量时间的合作项目，经过协商以后既有选择 JS 也有选择 TS 的。