对于复杂一点的项目，做一个详细设计非常重要。有人会疑惑，前端还需要详设吗？ 根据我的经验，详设非常重要，非常体现能力。对于一个新人，详设能够给开发做一些提前准备。对于一个老手，详设可以提前预见一些隐藏的坑。对于一个高手，详设需要达到随便给一个有点经验的人，都能直接写代码。

下面是我们部门总结的内部开发规范（试行版本），欢迎提意见。 部门FE React 组件开发规范 适用范围 部门FE 所有基于React开发的（包含fcui2）组件，欢迎提意见。 要求 必须：表示绝对要求这样做。 必须不：表示绝对不要求这样做。 应该/建议：表示一般情况下应该这样做，但是在某些特定情况下可以忽视这个要求。 应该不...

在我是如何优化网站首页性能的一篇文章中提到过95分位值的概念。下面从最近实际数据看看95分位值对于性能优化的参考价值。 真实数据 最近优化有了一些效果，就正好借着具体的实例数据来看看95分位值的意义。 看下面一张图： 性能平均值 从这个曲线中可以看出3月11号数据绿色的线升高了，出了点问题。 性能50分位值 50分...

作者：BrianLi （部门同事李老师，口头授权发布内部react布道资料） 无法用语言准确表达思维时，就用公式；一个不行，那就两个 —— 李老师 本文假设读者已了解react的基本概念，并有少量react开发实践。如果没有，请先阅读 [链接] 当前我们如何开发业务？ 备注：微信不支持公式，所以我这边截图。 补充一下f表示一次用m生...

A系统是一个古老的系统，B系统是一个新做的系统，（原本是希望A系统的功能全部迁移到B系统上的，但是由于各种原因搁置了）当时结果导致两个系统在同时使用和升级。

最近接到一个任务，首页性能优化。 目标：95分位值下 看到页面框架主体内容6s（优化前10s左右），优化提升40% 看到操作详细内容9s（优化前12s左右），优化提升25%。 侧面看出我们系统的庞大程度吧，这个不值得骄傲，项目比较悠久，历史包袱比较沉重，后面计划node同构方式去重构，但是现阶段需要一个低成本，短时间的方...

在一个庞大的商业系统中引入react这种数据驱动的模式。 希望能够一点点重构去替换以前的模块，逐步的将系统重要部分底层框架替换成react。

其中数据驱动的核心在于整个系统中对于数据的架构，设计，维护。对于数据的处理直接决定了系统的稳定性，可维护性，可扩展性。但是这里的数据维护也是相当复杂和难搞的一块。

他的背后不仅仅是数据驱动这么简单，在复杂的系统中，我觉得它解决了一个很关键的问题就是模块间的交互/通信。有很多文章拿他和mvc/mvvm去比较，我个人觉得没有特别的可比性，因为解决的问题不同。

模块化现在应该已经成为了稍微复杂一点前端开发的标配了。在es6中，都已经支持了的模块化。 之前的面试中，一直感觉模块化AMD,CMD没有什么可以问的，不过昨天面试突然想到一个题目：对于一个AMD的模式下 文件d.js如下 {代码...} a.js,b.js,c.js 文件分别是什么时候加载的，如何加载的？ 题目不难 答案是a.js 和 c.js 是...

关于『真阿当』对目前流行前端技术的批判 [链接] Winter - 我眼中的前端框架jQuery，Angular，React，Vue——以及我看前端架构[链接] 关于前端工具变化过快的讨论 [链接] 我感觉到的前端变化 [链接]

如何在项目中实现热更新中提到的一个坑child_process的exec使用问题，下面文章会详细介绍下，debug到node源码中的详细介绍，不容错过。

这个是组内一位同学在平时开发中，发现调试不便，为团队开发的热更新工具。很厉害，文章中的技术实现内容也是我了解了他的具体实现思路后，整理出来的。

最近项目中的一个模块正式引入的ES6，由于是引入新技术，也遇到了一些问题，下面分享下整个引入流程 为什么要引入ES6 最近在看一些前端解决方案的文章，ES6越来越多的出现在前端方案中。 ES6由于浏览器不支持，在使用上也是和CoffeeScript和TypeScript一样，都需要compile-to-JS。 理由一： 符合未来趋势，angular2就是...

sourceMap的偶遇 接触到sourceMap，其实是在调研ES6时发现的。 在调研ES6引入生产环境的可能性，初步觉得引入项目时需要解决的几个问题： 上线时的打包构建问题 开发环境编译问题，目前chrome都不兼容es6 解决了开发环境编译后，调试问题——开发的代码和浏览器跑的代码不一样 其他没有考虑到的问题等等 其中sourceMap就是...

推荐工具地址 [链接] 这个工具百度很多团队都在使用，现在开发了一版对外的，我觉得很赞。 我觉得工具的核心功能就是很好的解决项目延期的问题。 我个人对于这个工具的理解。 任务拆解 针对大型项目，任务拆解是非常重要的一块，如果没有合适的拆解，很多问题都会积压到项目deadline才集中暴露，如果暴露的问题太多或者...

教科书里面的setTimeout 定义很简单 setTimeout() 方法用于在指定的毫秒数后调用函数或计算表达式。 广泛应用场景 定时器，轮播图，动画效果，自动滚动等等 上面一些应该是setTimeout在大家心中的样子，因为我们平常使用也不是很多。 但是setTimeout真的有那么简单吗？ 测试题 一个题目，如果你在一段代码中发现下面内容...

首先聊聊我code review的经历，当时刚刚来到百度，负责FE这边的高T是从Google过来的，听说他将很多Google那边的风格复制到了百度，其中code review就是重要的一块。

随着前端复杂度的增加，技术债务就开始慢慢的在浮现出来。特别是系统级别的单页面应用，功能不断的叠加，技术不断的更新，架构不断的升级，技术债务就暴露出来了。

在很久以前，前端的部署其实比较简单，开发环境下，静态资源往服务器上面一扔就ok了，如果考虑下优化或者代码保护，也只是加一个代码压缩和混淆。没错，刚入行的时候我就是这么干的。。。