我觉得在 spa 成为普遍现象的今天，前端架构特别重要。
然后大多数的小团队单是跟进前端技术的发展就已经很费力了，这时候如果是一个前端技术工具方面玩的溜一点的，却缺少架构思维的人在早期来主导项目的代码结构的话，往往会成为整个项目的灾难。
在团队缺少架构高手的情况下，还是做多页应用来得更可控些，需要体验优化的页面就是自己做成一个简单一些的 spa.
这是我从之前两个项目中学到的教训。

我很无耻的说一下，感觉spa更简单，反而传统的多页面开发模式，更麻烦

请问每个逻辑页面如何可以做到独立发布呢？

关于组件化，我很不喜欢 react 中的 Functional Component 以及 HOC.
对于整个产品需求非常稳定情况来说，这样做也许没问题。把 UI表现和功能，按照不同的 perspective 去拆开，即所谓 separation by concern 的思路。
但对于一般的项目而言，往往需求变化都是比较频繁的，我认为更好的组件化方式是按功能切分。因为这样的组件内聚性比较好，会更便于代码阅读以及快速开发迭代。
在 React 上有些人比较推崇的那种纯 ui 表现类的组件，然后通过 HOC 来组装，实在是太绕了，完全不对我的胃口。

没有架构 项目用什么自己定 经常会很纠结用什么技术😂 有些想尝试的新技术 由于能力有限加项目通常都很赶 不敢实践到项目中 不加班的时候 会自己写些demo 折腾折腾

你好老师，现在管理的一个后台系统是JSP+Java合在一块的东西。想弄个功能类似上传视频，找到很多插件都是很久没有维护的，就在想要不要把这个前端JSP展示的部分提出来作为一个前端，后台只是作为一个core响应请求。如果是你的话，你会怎么做？
想问一下，想阿里的后台管理是怎么搞的，是不是前后端分离的，因为我知道阿里也是Java大户，像这种后台管理怎么做的？

如果项目只有我自己写的话 我会用新技术、自己不熟悉的领域去练习， 自己思考组价架构，设计模式等。。如果是多人协作 我可能就随大流了。。不敢瞎搞

spa好像不止hash一种实现方式，抛弃老版本浏览器的话，似乎可以利用history api，结合服务端url path接力，实现可前进后退的spa吧？我见过这样的 不知这种方式除了旧版本兼容性外 还有没有啥坑～

目前实现spa方面 是否有较为成熟的框架推荐

“实现单页应用的逻辑页面发布需要改造发布系统，在工程上，这也是一个比较大的挑战。” 老师，这句话是指单独发布部分逻辑页面么？

在公司闲着无聊搭了一套 React 的架子想推广，结果被 CTO 直接拍死，说国内这么多学 Vue 的你给我搞什么 React...😂😂😂

一个人撸到尾，github就是我的架构

感觉我们没有前端架构，就是撸代码。实现功能就行。

没有前段架构师，有部分人维护框架，但是架构升级或较大优化就没人了

自己写代码，自己规划架构。。。