> 如果是不是 IT 专业的小白，你们推荐什么呢？

我推荐 Obsidian 或者 LogSeq ，用过的都说好，

- 本地文件存储，不依赖网络
- 启动速度快
- 自带有文件树、搜索功能，方便查找笔记

不过这些软件有各种各样的插件，容易让人沉迷折腾笔记软件而不是写笔记本身。但是只要「懒得折腾」，它们开箱即用的体验适合大多数人。

床垫、货架、升降桌，这些东西都是使用一时爽，搬家火葬场。为了让搬家更舒适，可以选择那种完全不动手的搬家服务，价格是 300 元/立方米，10 立方起步。

根据你的问题，你应该

1. 排查内存占用情况
2. 加内存

切换到 Linux 并不能 100%解决内存不够用的问题

如果你只是想要一个借口说服自己折腾 Linux 桌面环境的话，我推荐 Arch + KDE ，这套配置我已经用 5 年了

超薄本很难有高性（运算性能）价（实际到手价格）比吧，放弃性价比的话，可以看看 YOGA Air 14s ， 板载 32G 内存，1.3kg 机身重量，非常便携，CPU 是定制的 R7 7840S ，性能也不差。目前最高配在 jd 售价 8299 元，也在预算范围之内。

https://i.imgur.com/zBZKCuC.png

两年肯辛通轨迹球用户，只能说轨迹球在操作的时候主要用的是手指，不用扭动手腕，对手腕比较友好，但是，这歀轨迹球的按键开关个人感觉有些硬，点击操作多了，手指根部会酸。总结，还是尽量多用键盘吧。

感觉你在找 FFI ，对于 Java 来说就是 JNI ，对于 C# 来说，需要通过 NativeAOT, P/Invoke ，别说混合 Java 了，混合任意支持 FFI 的技术都可以。通过这种方式互相调用肯定有影响的，主要消耗应该都在数据交换上面，建议参考文档推荐的方式编写代码、设计程序。

https://en.wikipedia.org/wiki/Java_Native_Interface
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/samples/NativeLibrary
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke

我的方案是浏览器装个 Grammarly 插件纠正输入错误，另一方面，我也会通过 https://writeandimprove.com 练习写作。

@MinonHeart #4

> 两边都是通过 cache 提速的，另外 TPR 的项目依赖需要手动编写（ tsconfig.json ），和 package.deps 重复了，维护不会很麻烦吗？（有看过一些同步的工具，但是还是挺麻烦的）

在我的项目中，维护 tsconfig.json 的 reference 用的是自己开发的工具 https://github.com/ZeekoZhu/js-prelude/blob/main/packages/ts-sync-ref/README.md ，把这个包装成 nx executor 后，就方便很多了。

> js 和 ts 混合项目，TPR 怎么处理？

TPR 只是用来加速 tsc 而已，tsc 查找类型定义的方式可以通过给 tsc -b/-p 命令加上 --traceResolution 来 debug 。你的这种做法看起来也没啥问题。另一种做法是通过 package.types 字段指定 .d.ts 文件。

> TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

我把 tsc 当作 type checker 用的，生成 js （包括 copy assets ）用的是 vite ，跟 tsc 没有任何关系。另外，build mode 提升构建速度的方式是复用类型定义，也跟二进制文件没有关系。

> TPR 在 watch 和 build 上有很大的优势吗？

这里我引用一下 TypeScript 的文档：

> By separating into multiple projects, you can greatly improve the speed of typechecking and compiling, reduce memory usage when using an editor, and improve enforcement of the logical groupings of your program.

如文档所述，启用 Project Reference 后，tsc 跟 tsserver(language server) 都会变得更加高效。我实际测试下来，类型检查速度能提速不少；编辑器的话，我平常用 WebStorm ，这个 IDE 根本不用 lsp ，所以没有感觉到内存占用的减少。

@MinonHeart #2

> TPR 中不同项目导出同名类型会导致类型错误

没法复现你说的这个问题，https://i.imgur.com/PvW0haX.png

讲道理不同模块下出现同名类型的情况很常见，只要同一模块下的类型名称不重复即可

> Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

确实这俩都支持增量构建，但是 nx 的适用性更加广泛。我自己的使用中，tsc 负责把代码编译成 d.ts ，nx 负责缓存各种构建产物（ tsc, vite, webpack, svgr 等等），所以从定位上，nx 是个构建工具，而 TPR 只是用来给 tsc 加速而已，类似的，vite, webpack 之类的也有构建缓存功能，但是使用这些工具跟 nx 并不冲突。

最后，往一个项目中引用的工具越多，项目都会变得越复杂，比如很多人吐槽的新建一个前端项目模板，页面代码没几行，净是 .xxxrc 。我觉得这类问题目前看来是无解的，这是为了提高开发体验做的牺牲。不过，我觉得引入 nx 能够缓解手动维护这些配置文件的繁琐，靠官方、社区维护的插件，已经能够在创建项目、升级依赖的过程中简化很多操作了。

界面丑跟前端技术无关，主要是设计功力不足。所以我建议楼主看看这本书 https://www.refactoringui.com ，本书的作者同时也是当下流行的前端技术框架 tailwind css 的作者，这本书提供了对于程序员而言很实在的技巧，旨在教你如何在没有设计师的帮助下，设计出美观的网页

准备一个测试环境，前后端写好了代码就往测试部署，这样两边谁也不耽搁谁

如果各位有兴趣的话，也欢迎在评论区分享你的项目中执行类型检查的方案。

我现在用 lsyncd 远程开发，代码 clone 到自己电脑，然后用 lsyncd 同步到 Server ，webpack dev server 之类的都在 Server 上运行，这样可以减少自己电脑的内存消耗，而且不会降低开发体验。

@daliusu #22 试试 2023.2 呢，现在支持 LSP 了，应该就有 volar 的智能补全了

轻量与功能丰富不可兼得

我也蹭楼分享一下我的键盘设置，不过我主要在 Linux 下使用 https://zeeko.dev/2022/11/free-ergonomic-keyboard/

@serco #30
说得对，crate json 要比 serde_json 快一倍（ AMD Ryzen 7 5800U ）

```rs
// build with cargo build -r
use std::fs::File;
use std::io::{Read};

use serde_json::Value;
use json;

fn parse_json(contents: &Vec<u8>) {
let now = std::time::Instant::now();
let _: Value = serde_json::from_slice(&contents).unwrap();
let elapsed = now.elapsed();
println!("serde_json: {:?}", elapsed);
}

fn parse_json2(contents: &str) {
let now = std::time::Instant::now();
let _ = json::parse(&contents).unwrap();
let elapsed = now.elapsed();
println!("json: {:?}", elapsed);
}

fn main() {
let contents = {
let mut vec = Vec::new();
// https://github.com/json-iterator/test-data/blob/master/large-file.json
File::open("large-file.json").unwrap().read_to_end(&mut vec).unwrap();
vec
};
for _ in 0..10 {
parse_json(&contents);
}
for _ in 0..10 {
// create json str from contents
let contents = String::from_utf8(contents.clone()).unwrap();
parse_json2(&contents);
}
}

```

```
serde_json: 182.566705ms
serde_json: 157.330185ms
serde_json: 151.551179ms
serde_json: 150.997928ms
serde_json: 158.290287ms
serde_json: 151.983899ms
serde_json: 152.493476ms
serde_json: 150.337436ms
serde_json: 151.174303ms
serde_json: 150.424319ms
json: 71.080736ms
json: 73.125015ms
json: 80.531158ms
json: 82.744729ms
json: 79.73645ms
json: 80.040878ms
json: 80.30521ms
json: 79.455428ms
json: 79.702968ms
json: 72.22127ms

________________________________________________________
Executed in 2.42 secs fish external
usr time 2.36 secs 0.00 micros 2.36 secs
sys time 0.06 secs 464.00 micros 0.06 secs
```

当然，你换个编程语言也可以比 serde_json 更快

```fs
/// build with dotnet build -c Release
open System.IO
open System.Text.Json
open System.Diagnostics

let json = File.ReadAllText("large-file.json")

for i in 1..10 do
let sw = Stopwatch.StartNew()
let jsonDocument = JsonDocument.Parse(json)
sw.Stop()
// print in ms
printfn "Elapsed: %dms" sw.ElapsedMilliseconds

printf "Done"
```

```
Elapsed: 185ms
Elapsed: 74ms
Elapsed: 73ms
Elapsed: 70ms
Elapsed: 75ms
Elapsed: 74ms
Elapsed: 67ms
Elapsed: 69ms
Elapsed: 73ms
Elapsed: 73ms
Done
________________________________________________________
Executed in 963.57 millis fish external
usr time 881.76 millis 0.00 micros 881.76 millis
sys time 86.87 millis 387.00 micros 86.48 millis
```

用最熟悉顺手的编程语言就好了，先把工具写出来，再考虑优化。

https://i.imgur.com/jjNYfBH.png

Wayland +KDE 可以，但是存在一些不是特别影响使用的问题