前端架构：前端架构有哪些核心问题？
winter
该思维导图由 AI 生成，仅供参考
你好，我是 winter，今天我们来谈谈架构。
在传统桌面软件开发中，架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。
在工程领域，我们凡是要做点什么事儿，都会有明确的目的性，这个目的性，一定是为了完成生产服务业务的。
为什么桌面软件开发需要架构师和架构设计呢？因为桌面软件开发具有高度的复杂性，如果没有架构，就没法分解成互相耦合低的模块来分工。
所以一般来说，架构是为了分工而存在的。但是到了前端领域，这个问题是否还存在呢？答案是，不存在。
前端是个天然按照页面解耦的技术，在多页面架构中，页面的复杂度大约刚好适合一个人的工作量。（所以，我们的结论是，前端根本不需要架构设计。当然，我这句话是开玩笑的。）
前端不存在分工问题，但是在多人协同时，仍然要解决质量和效率的问题，这就需要组件化了。除此之外还有前端特有的兼容性问题，也是需要从架构的角度去解决的。
对于一些追求极致的团队来说，会挑战“单页面应用”，通过单页面应用来提升用户体验，单页面应用的升级版本是谷歌提出的 PWA，PWA 既是业务方案也是技术方案，在技术层面，它近乎苛刻地规定了网页的各方面的体验标准。
前端领域还有一个特有的生态：框架，第一代前端框架（如 jQuery, PrototypeJS）重点解决了兼容问题和 API 的易用性问题，在现代浏览器普及之后，这些问题逐渐变得不存在或者不重要，所以第二代前端框架（如 Vue，Angular，React）重点解决了组件化问题。选择合适的框架，可以节约架构的成本，还能够享受社区资源。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
前端架构在传统桌面软件开发中扮演着重要角色，但在前端领域却存在着不同的挑战和需求。本文从宏观角度介绍了前端架构的核心问题，包括组件化、兼容性和适配性、单页应用以及扩展前端新边界。在组件化方面，介绍了Web Component、Vue、React、Angular等主流选择，以及其特点和适用场景。兼容性和适配性问题也得到了讨论，特别是针对移动时代的屏幕适配问题。此外，文章还探讨了单页应用的概念及其挑战，以及前端架构在拓展前端边界方面的尝试。总结时，强调了前端架构需要解决的核心问题，并留下思考问题，引发读者对团队中前端架构师的工作职责进行思考。整体而言，本文全面介绍了前端架构的技术特点和挑战，为读者提供了对前端架构的深入了解和思考。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《重学前端》，新⼈⾸单¥59
《重学前端》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(20)
- 最新
- 精选
爱学习的大叔感觉我们没有前端架构，就是撸代码。实现功能就行。作者回复: 每个人都觉得是别人的事，但是总得有人第一个做。
2019-07-1526
靠人品去赢你好老师，现在管理的一个后台系统是JSP+Java合在一块的东西。想弄个功能类似上传视频，找到很多插件都是很久没有维护的，就在想要不要把这个前端JSP展示的部分提出来作为一个前端，后台只是作为一个core响应请求。如果是你的话，你会怎么做？ 想问一下，想阿里的后台管理是怎么搞的，是不是前后端分离的，因为我知道阿里也是Java大户，像这种后台管理怎么做的？作者回复: 在现代服务端架构中，视频都是需要CDN支持的，所以很难通过“插件”来解决，这跟你的服务端架构强相关，如果是我的话就直接扔给云存储，后面用服务端逻辑解决。
2019-07-083
sugarspa好像不止hash一种实现方式，抛弃老版本浏览器的话，似乎可以利用history api，结合服务端url path接力，实现可前进后退的spa吧？我见过这样的 不知这种方式除了旧版本兼容性外 还有没有啥坑～作者回复: 你说的没错，但是history api配合URL就需要服务端做很多事情了，这个是个综合架构问题，目前我还没见过特别好的案例
2019-10-102- sugar目前实现spa方面 是否有较为成熟的框架推荐
作者回复: 这个我不太了解，目前社区方案我没有太满意的。
2019-10-101 
阿成我头铁，直接上新技术（react+hooks），因此遇到不少坑，不过是个小项目且只有我在做啦😂😂😂 怎么说，我觉得有时候还是要大胆一些... 当然多人协作的项目就不要搞人家了...2019-05-1836
Neil 陈荣我觉得在 spa 成为普遍现象的今天，前端架构特别重要。 然后大多数的小团队单是跟进前端技术的发展就已经很费力了，这时候如果是一个前端技术工具方面玩的溜一点的，却缺少架构思维的人在早期来主导项目的代码结构的话，往往会成为整个项目的灾难。 在团队缺少架构高手的情况下，还是做多页应用来得更可控些，需要体验优化的页面就是自己做成一个简单一些的 spa. 这是我从之前两个项目中学到的教训。2019-05-1818
行云我很无耻的说一下，感觉spa更简单，反而传统的多页面开发模式，更麻烦2019-05-2211
行则将至请问每个逻辑页面如何可以做到独立发布呢？2019-05-218
佚名在公司闲着无聊搭了一套 React 的架子想推广，结果被 CTO 直接拍死，说国内这么多学 Vue 的你给我搞什么 React...😂😂😂2019-07-2356- Neil 陈荣关于组件化，我很不喜欢 react 中的 Functional Component 以及 HOC. 对于整个产品需求非常稳定情况来说，这样做也许没问题。把 UI表现和功能，按照不同的 perspective 去拆开，即所谓 separation by concern 的思路。 但对于一般的项目而言，往往需求变化都是比较频繁的，我认为更好的组件化方式是按功能切分。因为这样的组件内聚性比较好，会更便于代码阅读以及快速开发迭代。 在 React 上有些人比较推崇的那种纯 ui 表现类的组件，然后通过 HOC 来组装，实在是太绕了，完全不对我的胃口。2019-05-1854
收起评论