@neiltroyer849 我尝试过关了 ITP ，问题依旧，难点是这 bug 在 Safari 15 上是好的，Safari 17 上就不行，然后我又不能要求每个用户去手动关 ITP……打算暂时先做个弹窗提示下不要用 Safari 了……没辙

@emartcn native 性能还是好很多的

@moving80kg 对的，我跟你的历程几乎是一样的，我去年开始做自己的 SaaS ，最开始也是自己写 auth （而且我之前有几次集成 OAuth 的经验），后来发现要把 auth 写好（好用 + 健壮 + 安全），不是一件容易的事。我之前也集成过 auth0 ，不过 auth0 一来是费用贵，二是对国内的访问速度也蛮慢的，所以后来调研别的解决方案，发现了 logto ，还是蛮好用的。

我自己写 auth 过程中最大的痛点还是 account linking ，就是多种登录方式在系统中链接到同一个 account 的问题，很多商业产品其实这一点做的也是不够好的，很容易让人困惑，logto 比较好的解决了这个问题。

接入专业的 auth solution 后确实这块不用怎么管了，毕竟我是做我自己的 SaaS ，不是做 auth 的哈哈。

跟楼上 @wuyuandev 和 @nicoljiang 相反，我是自己先写了 auth ，之后又花时间全部迁移到了 logto ，也是自托管，用了快小半年了，还是非常非常推荐了。

当然，自托管确实还是有一些部署和运维上的复杂性，SRE 方面比较弱的小伙伴们，还是推荐用下 logto cloud ，蛮好的。

写的两篇迁移到 logto 的文章：

- [Introducing the New Auth Flow for PPResume]( https://blog.ppresume.com/posts/introducting-the-new-auth-flow?utm_source=v2ex&utm_medium=xiaohanyu&utm_campaign=logto-protected-app)
- [Introducing Google Sign In for PPResume]( https://blog.ppresume.com/posts/introducing-google-sign-in?utm_source=v2ex&utm_medium=xiaohanyu&utm_campaign=logto-protected-app)

仅供参考哈

---

Protected app 的 idea 蛮好的，个人感觉依照 express middleware 的方式，通过一个 proxy 来抽离出 auth layer ，very smart 。就我个人体验而言，接入 logto 作为一个第三方的 auth server ，因为要同时在前端和后端都验证 auth token ，所以要接入两套 SDK ，还是有些复杂度的。

不过目前看上去 protected app 功能可能还是比较有限，跟 SDK 的接入还是无法对标的。看场景啦。

@LeeReamond 还是不容易的，因为 motion 是个动态的东西，你去趴别的人网站，看别人的实现，然后来实现自己的，相当于，给你一堆食材，让你自己做顿美味，如果你没有经验的话，不容易。很多 motion 的设置其实并不是 linear 的值。

专业团队有专门做 motion design 的（算是 UX 下面一个很重要的分支），具体你可以搜下这种岗位的需求。

开源实现方面，可以看下 neon database 的网站： https://github.com/neondatabase/website 。

供参考哈。

如果是想要更大的灵活性（甚至一些可编程性的话），可以看看 retool： https://retool.com/ 或者其他类似的工具，国内应该有同类的竞品，自己可以去查查

海外的 SaaS 工具：

- https://tally.so/ ，有免费额度
- https://www.typeform.com/

“过渡的动画样式比较丰富的” 这点其实满难搞的，首先就是 CSS 的过渡（ transition ）和动画（ animation ）的 API 就有一大堆，然后也不太好学；再就是用得太多的话，网站也比较容易卡顿；还有就是，良好设计和规划的过渡和动画是 UX 的事情，程序员自己想出来的往往都是有问题的……这个是蛮专业的领域，大规模的团队是有专门的职位搞过渡和动画的。

建议只有框架内提供的基本的一些过渡和动画，不建议自己搞太多。

我了解到的一个比较好的应用过渡和动画的网站： https://www.relume.io/ 。看一下就知道，没有专业的 UX 团队，靠程序员自己是很难搞出这种效果的了。

总体上讲，react 的 UI 库选择还是比 vue 要丰富多了，不过学习成本是比较高的，如果只是做个静态的 landing page 或者交互性不多的网站，传统的 jQuery 方案，以及基于 jQuery 的各种 UI 库（ Bootstrap 之类）就是成本最低的选择，简单+容易上手+海量的模板选择。

Tailwind CSS 写起来比较快，不过项目规模大的话，几十个 class 写在一起，很难维护的。

程序员自己搞网站，没有设计师的话，注意 font/spacing/grid/color pattern 这几个基本点，保证全站的统一，然后不要引入太花哨的东西，再参考已有的一些设计，基本上是可以搞出一个及格的设计的。Tailwind 作者有本叫 refactoring UI 的书，写得蛮好的，可以参考下。

我自己用 react UI 库（ https://mantine.dev/）写的 SaaS： https://ppresume.com/ ，一个基于 LaTeX 的简历生成器。自认为还是做到了“简单”、“好看”的标准的。

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

[讨论]( https://v2ex.com/t/1030970)

仅供参考哈。

@kile 啊，PrimeReact 和 Chakra UI 我都没用过呢，不过我粗略看了下，觉得 mantine 有几点还是很有优势的

1. 组件更丰富，比较常用的 DatePicker, MonthPicker ，Chakra UI 没有： https://mantine.dev/dates/month-picker/，PrimeReact 有个 Calendar 组件，但是不如 mantine 的 DataPicker/MonthPicker/YearPicker 强大，再比如 Rich Text Editor： https://mantine.dev/x/tiptap/，这两个重量级组件在我的产品 PPResume 中都是重度使用的。Mantine v7 还加入了对 Charts 的支持： https://mantine.dev/charts/getting-started/
2. hooks 更多，参见： https://mantine.dev/hooks/use-click-outside/，对比 PrimeReact： https://primereact.org/hooks/usemounteffect/ 和 Chakra UI： https://v2.chakra-ui.com/docs/hooks/use-boolean 。
3. style 定制，mantine 提供特别丰富的 style 定制方式，最重要的是和一般 UI 库不同，mantine 可以定制选择 internal child components ，而不像大多数 UI 库只能通过传 className 的方式定制最外层的 component ，参见： https://mantine.dev/styles/styles-overview/ 和 https://mantine.dev/styles/styles-api/，当然 Chakra UI 和 PrimeReact 也是提供了 component style 定制的 API ，比如 Chakra UI： https://v2.chakra-ui.com/docs/components/slider/theming ，但是好像用的是自己的 DSL ，不知清楚是否可以用全部的 CSS ，mantine v7 用的是 CSS module ，可以利用全部的 CSS 属性的，Prime React 的 styling： https://primereact.org/calendar 。我总体感觉 mantine 的 CSS module 还是更舒服一些 ，性能也更好一些（ mantine v6 -> v7 是升级到了 CSS module ）

说的不一定对哈，供参考。

---

背景：我最开始写 PPResume 是用 tailwind ，后来花了点时间全部迁移到了 mantine ，经历了从 v5 -> v6 -> v7 的升级，总体对这个库还是非常满意的。

@kile Mantine: https://mantine.dev/ ，个人用过的最强大的 react UI 库，强烈推荐。最开始也是用的 tailwind ，后来迁移到了 mantine： https://github.com/orgs/mantinedev/discussions/6111

TS 一把梭写了个自己的 SaaS 产品： https://ppresume.com （一个基于 LaTeX 的简历生成器），13 KLOC 代码左右，感觉还是非常有帮助的，引入的成本不大，也没必要去生硬去抠类型体操，但是对开发流程和体验的优化还是很有帮助的。当然，如果只是临时写写一些几十几百行的脚本，TS 提升有限。

@demonps 嗯，章节顺序重排，还有自定义章节其实很多人提过，我也有列过计划： https://github.com/ppresume/community/issues/5 ，https://github.com/ppresume/community/issues/12 ，最近刚刚有点时间来着手做这些，不过在做章节重排之前还要先把后端底层的数据结构再重构一下，快的话估计一个月左右可以上线了

前后端都用 JS/TS 还有一个好处，就是利用 npm/yarn workspace 这种功能，可以将部分前后端共享的代码抽出来共享，比如一些数据类型定义，一些 utility 等等（楼上也有人提到了 trpc 这种方案，我没有用过）。

@raw0xff 并不是的，next.js 的代码有一部分会在前端浏览器里运行，另一部分是在后端运行的，后端的就不用说了，前端的代码也是经过编译和混淆的，基本上也是不可读的状态。

用 Next.js 写了自己的 SaaS 产品： https://ppresume.com ，大概 13k 代码左右。

Go + Next.js 肯定是没有问题的。不过根据场景，也需要具体的技术选型。

- 纯 SPA 程序？用 react 就行
- 有搜索 SEO 需求？最好 next.js ，加上单独的后端
- 后端和 next.js 通信又有几种方式，可以采用 next.js 前端和 Go 直接通信，也可以 next.js 的前端 -> next.js server -> go server 通信

如果有比如重的 content management 需求，或者需求一个 admin dashboard ，可以考虑采用一些 headless CMS ，如 strapi 这种直接生成后端，这就是非 Go 的后端方案了。

@demonps Hello ，生僻字的问题已经暂时修复了呢，切换了下后端模板对中文的字体，issue: https://github.com/ppresume/community/issues/33

@demonps 这个可能是 pdf viewer 的 character map 的问题，回头我看一下。

自定义位置，指的是不同的 section （比如 工作，教育 ）这些可以调整位置对吧？如果是这个需求的话，我最近在开发了。

@lstz 没用过哈，不过我感觉 PPResume 其实并不算 data intensive application 哈