增加一个 Mobile App Backend ，统一处理 App 发起的请求和维护后台配置，解决问题并且增加就业。

14 pro max 用户被恶心到了。

共用省资源，独立好维护。

@enchilada2020 Node 近十年的强势在于前后端分离，即使前后端都用 Node 但也是基于不同的框架不同的思维，用 API 来跟前端沟通。

近今年出现真正的全栈 Node 框架，例如 Next.js 和 Remix 。最近 Next.js 因为 React server action 引起争议，被嘲讽终于追上了 PHP 。我觉得 Next 把整个应用都放在 React 的抽象层里很有勇气，也可能会遇到很多问题，我持观望态度。接下来 Node 社区可能会分裂为前后端分离和全栈两个派别。所以我觉得 Node 的全栈其实还不成熟，未来还需要踩很多坑。

Ruby on Rails 今年 20 周年，确实热度下来了，新人寥寥无几，但是坑都被踩得差不多。7.0 版本终于把前端梳理好了，可以用上前沿的 importmap 期待未来的 turbo 8 （ Morphing ），进一步改善前端的开发体验。不喜欢 Rails 默认栈也可以换其他主流前端工具，jsbundling 方案可以灵活适配。

使用无聊的技术反而有利于生产力，因为不用去踩未知的坑，更多精力花在产品上。

Choose Boring Technology https://boringtechnology.club/

“其他”包含了国外的测试点，会拉低平均，把“其他”去掉。

@enchilada2020 Python 的框架没有全栈的野望，Node 在全栈还有很长的路要走。

如果有志于往全栈发展，那应该看 https://rubyonrails.org/ 框架。因为它是为数不多的 The One-Person framework ，而不是 Part-Stack Developer 框架。

今年的 Rails World 演讲：

https://www.youtube.com/watch?v=iqXjGiQ_D-A

Turbo 标语

> The speed of a single-page web application without having to write any JavaScript.

https://turbo.hotwired.dev/

使用 Turbo 的功能几乎不用写 JS ，Turbo 也不会阻止你的代码用不用 TS ，不知道激动啥……

想起 Atom Editor 1.0 的宣传片

https://www.youtube.com/watch?v=Y7aEiVwBAdk

别吃蘑菇，因为有菌。

从顶楼的内容还看不出用 vue 或 react 的必要。

数据图库一般是比较独立的库，前端框架 vue 或者 react 不是必须。有的库为前端框架做了适配，这样只是在这些前端框架里使用这个图库比较方便，而不是必须。

数据图库一般的工作方式是由页面或者 API 输出数据，用 JavaScript 调用初始化。这些工作一般的 Web 框架都能实现，你用你们熟悉的语言的 Web 框架就行了，先把最小可行性产品（ MVP ）做出来。

至于编辑操作，还不清楚复杂到什么程度。如果只是简单的修改数据，更新页面，可能还用不到前端框架，普通的表单 Ajax 就满足了。当你页面逻辑复杂到不得不用前端框架的时候，那时候就懂得判断选哪个前端框架了。

另外看楼主没提到，这里推荐一个数据图库 https://www.chartjs.org/ ，我觉得比较简洁美观，不知道是否满足楼主需求。

- next.js 的 ssr 按我理解是混合结构，每个页面可以在服务端渲染，然后在客户端绑定行为，之后的交互走客户端，切换页面和 csr 没什么差别。
- ssr 的公共内容可以缓存，节省了一些渲染和查询时间。
- ssr 可以优化首屏载入时间。
- 移动设备客户端性能并不总是令人满意。

我认为 Web 开发前后端分裂是很奇怪的事情，切割两端并不是最佳方案，未来还是会回到全栈。

当你发现 Mac 卡住了，它其实是卡住了。

可以增加工作岗位。

https://getbootstrap.com/ 配合自己熟悉的服务端 MVC ，不依赖 react / vue 之类的前端框架。