随心笔记
1、Bun
一个新的js运行时，使用JSC（javascriptCore）内核。比node快3倍，完全兼容历史代码，可以无缝迁移，但是现在还在开发阶段。
- 安装（只能是mac或者Linux系统）
curl https://bun.sh/install | bash
记得添加path
- 创建一个文件
script.js
Bun.serve({
fetch(request){
return new Response("Hello World")
}
})
console.log("Listening on Port 3000")
-
运行
bun run script.js -
访问
localhost:3000
参考
Bun: The JavaScript runtime taking on Node.js and Deno
A first look at Bun: is it really 3x faster than Node.js and Deno
2、时间库横向对比 结论
不推荐： Native Date, Moment.js(不维护了)
轻量使用推荐：Day.js
推荐：Date-fns
3、不可变对象 -> 类似深拷贝
immer
cloud.tencent.com/developer/a… github.com/immerjs immerjs.github.io/immer/zh-CN…
4、tauri
Tauri 是一款应用构建工具包，让您能够为使用 Web 技术的所有主流桌面操作系统构建软件
5、Web Components
Omi是腾讯开源的前端跨框架跨平台的框架。是下一代 Web 框架，Omi 的目标是去万物糟粕，合精华为一。Omi 是一个跨框架的框架，任何框架都可以使用 Omi 自定义原始，当然 Web Components 也可以
6、cypress vs jest
Conclusion1
We'll use both Cypress and Jest to help with our testing. These tools, in our opinion, work best together and will enable us to achieve adequate code coverage. Since we have found Cypress to be quite user-friendly, we will use it for our end-to-end testing. We will use Jest for our unit tests because we have observed how well-used it is in many larger organisations.
Conclusion2
I'm learning both Jest and Cypress at same time. I know that they are not direct competitors because Cypress is focused on E2E and Jest on unit testing. For now I have implemented in my project both Jest and Cypress with few tests.
But actually most things I can test in both Cypress and Jest, and often I have hard time to decide with what write my test. Also it is harder to maintain compared to single test library.
I'm wondering - how often is Cypress (or alternative) and Jest (or alternative) used together? Is it really standard and good practice to use both? Or most developers/teams sticks with single one solution and it is fine?
Update edit: It was a long time since this question was asked. I got compromise that was also suggested in comment. Instead using only Cypress or Cypress + Jest, I'm using Cypress + new Cypress Component Testing (so no Jest). Thanks to that I'm having same library and assertions (easier to manage) but can test both e2e and components.
7、nextjs vs Remix
| Next.js | Remix | |
|---|---|---|
| SSG静态站点生成 | ✅内置 | 🚫不支持 |
| SSR服务器端渲染 | ✅内置 | ✅通过 loader |
| API 路由 | ✅pages/api/ 目录下 | 🚫Remix 就是路由，你可以更加灵活去进行自定义路由 |
| Forms表单 | 🚫 非内置 | ✅ 内置，且功能强大 |
| 基于文件系统的路由管理 | ✅ 页面级 | ✅ 组件级 |
| 会话管理 | 🚫 非内置 | ✅ 内置 Cookie、Sessions |
| 禁用 JS | 🚫 未提供充分支持 | ✅ 静态页面路由 |
| 样式 | ✅ 提供了全局及组件级样式支持 TailwindCSS 等 | 🚫 非内置 |
| 嵌套布局 | 🚫 不支持 | ✅内置 |
| i18n国际化 | ✅内置 | 🚫 非内置 |
| 图片优化 | ✅通过 next/image 组件 | ✅通过简单转换、备选质量等方式 |
| 谷歌 AMP | ✅内置 | 🚫 非内置 |
| 适配器 | Node.js Request 和 Response 接口 | Fetch API Request 和 Response 接口 |
| Preload | 链接自动 | 非自动 |
| 异常处理 | 创建 404，500 等页面 | 使用 ErrorBoundary 组件局部抛错 |
| Polyfill | fetch、Object.assign 和 URL | fetch |
8、Zustand VS Redux VS Jotai VS Recoil
| 差异 | Zustand | Redux | Valtio | Jotail | Recoil |
|---|---|---|---|---|---|
| Need Context | No | yes | No | No | Yes |
| Render Optimization | selectors | selectors | property | auto dependency | auto dependency |
9、react-window vs react-virtualized
So there’s that! react-virtualized is a great project, but it may do more than you need. However, I would recommend using react-virtualized over react-window if:
- You’re already using react-virtualized in your project/on your team. If it ain’t broke, don’t fix it — and, more importantly, don’t introduce unnecessary code changes
- You need to virtualize a 2D collection that is not a grid. This is the only use case that react-virtualized handles that react-window has no support for
- You want a pre-built solution. react-virtualized has code demos for all its use cases, while react-window just provides virtualized list primitives so you can build off them. If you want docs and pre-made examples with more use cases, then the heavier react-virtualized is for you
