Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a web-frontend-overview
Semelhante a web-frontend-overview (20)
web-frontend-overview
- 2. 自我介绍 • 张立理 – Gray Zhang – otakustay otakustay @icloud.com otakustaygithub.com/ otakustaystackoverflow:
- 3. 自我介绍 • 工作6年，专职前端5年 • 2010年加入百度，现T7，前端架构师 • 百度EFE组RIA技术方向负责人 • 擅长大型前端系统设计&建设，第三方脚本实现 • 爱好摄影、驾驶 • 宅、家里蹲
- 7. 前端的职责 • 产品需求 • 交互设计 • 视觉设计 输入 • 逻辑实现 • 设计还原 • 前后接口 • 系统构建 • 发布部署 过程 • 面向用户可用的界面 • 流畅一致的使用体验 • 回馈后续产品设计 输出 • 问题监控&修复 • 性能监控&优化 • 用户行为追踪&统计 • 细节体验优化 支撑
- 8. 编码内容 HTML（内容） •文字 •图片 •按钮 •文本输入 CSS（外 观） •颜色 •背景图片 •字体字号 •摆放位置 JavaScript （逻辑） •点击、输入 •数据获取 •计算校验
- 10. 知识体系
- 11. 基本技能栈 程序逻辑 数据结构 基本算法 HTML JavaScript CSS Emmet Coffee ES Next SASS Stylus DOM BOM 布局 动画 响应式语义性 异步管理 面向对象 函数式 设计模式 MVC MVVM XHR JSON jQuery underscore iscroll zepto React Sencha ECharts Angular Ember 基础知识 编程语言 应用接口 库 框架 解决方案 学习 编码 生产 英语
- 15. CSS 使用方式 • link • style • inline • @import 语法 • CSSOM • @rule • 选择器 • 属性 • 伪类、伪元素 • 媒体选择 属性值 • 数字 • 长度 • 颜色 布局 • 盒模型 • 浮动 • 定位 • 表格 • 边距折叠 • 展现层级
- 18. 模板输出 后端业务逻辑 提供页面数据 定位模板文件 前端编写模 板内容 服务器将模板转为 HTML输出 • 优点 直接输出HTML，用户体验好 对搜索引擎友好 可基于最终HTML集成测试 • 缺点 不同框架模板语法不同造成学习成本 循环生成HTML冗余，网络传输量大 动静资源难以独立维护、上线、部署 难以针对静态资源做CDN等运维优化 模板渲染与业务代码不可物理分离 • 常见场景 跨职责工程师团队 访问量中等的多页式传统项目
- 19. 动静分离 后端提 供数据 接口 前端编 写模板 纯前端渲染 • JavaScript请 求数据 • 前端模板引擎 • 优点 职责分离，高效开发 动静分别管理、上线、部署、运维，可针 对性优化各个环节 数据相比HTML体积小，网络性能更佳 可结合双向绑定等技术提升前端开发效率 • 缺点 难以进行SEO（搜索引擎优化） 需较重量级前端框架支撑 页面需多份数据往往要请求多次，造成 HTTP请求数量较多影响性能 • 常见场景 单页式应用 单职责形开发团队
- 20. 中间件 • 细粒度 • 控制授权和权限 后端提供数据 接口 • 聚合数据接口 • 定位模板 • 生成HTML输出 • 控制缓存等优化 前端维护 NodeJS中间件 • 优点 前端熟悉NodeJS技术，模板语法固定 后端数据接口无需照顾前端展现形式 NodeJS擅长IO密集形应用，可提升性能 业务逻辑与中间件可分离部署，在服务器 配置、运维手段等方面针对性优化 NodeJS可进行部分客户端JavaScript预执 行和渲染 • 缺点 NodeJS不够成熟 增加故障点 • 常见场景 高并发高PV压力的系统
- 21. 混合式 • 优点 混合动静分离与中间件模式 灵活性极高，前端可自由选择获取数据或者HTML 中间件可用状态下由中间件进行模板渲染及输出 中间件不可用时前端直接获取后端数据接口 前端组件可在中间件进行预渲染 • 缺点 技术难度较高 中间件不可用时后端压力增长，需要完善扩容方案 代码不易复用，相同逻辑往往中间件与前端重复编写 • 常见场景 基于React组件解决方案的应用
- 23. AngualrJS • 场景 界面操作混乱、复杂，不易测试 DOM开发效率低下，易出错 • 解决方案 数据生成界面，数据变化产生界面变化 双向绑定，界面变化回馈数据变化 • 优点 开发效率高，大部分场景只关注数据 • 缺点 复杂应用场景下数据关系易产生混乱 重型解决方案，不可分拆性
- 24. React • 场景 维护数据关系容易混乱，数据所有权不明，一份数据多处修改容易丢失一致性 数据变化自动生成界面变化效率不高 • 解决方案 引入函数式编程理念，强调数据不变性 组件通信使用事件机制，避免对数据的多端修改 虚拟DOM优化界面性能 新的语言JSX提供辅助 • 优点 数据管理清晰，变更流动可控，系统健壮 • 缺点 应用层面不隐藏组件存在，测试困难
- 25. Webpack • 场景 模块化开发成为主流，构建工具却依旧以文件为单位 依赖管理分散，逻辑模块自主管理依赖，其它依赖无处声明 非全局性地构建单个模块较为麻烦 • 解决方案 以模块为核心的构建系统 所有资源均为模块，统一依赖管理方式 • 优点 与模块化设计/开发配合效果优秀 • 缺点 与编码方式相关，下游影响上游
- 26. Q&A
Notas do Editor
- 最简单且合法的HTML是什么样的 什么时候用背景图片，什么时候用<img>标签 压缩HTML时哪些可以移除 多个空行是否可以压缩成一个，是否可以一个不剩
- 即便基于React可以相对方便地进行这种模式的开发，依旧少有团队采纳混合式作为主要开发模式，因为ROI太低