除了前边梳理的知识之外，前端还涉及到很多其他知识，这里咱们有的没的随便唠唠
- 构建工具
- 对比Fis和webpack
- webpack配置简介
- 架构及选型
- 架构比较总结
- 架构比较细节
- 移动端适配
- 基础概念
- 适配解决方案
- 关于源码阅读
- 版本控制
- 终端命令
- node
构建工具
我司老旧项目用的都是百度的Fis
新项目使用现在流行的webpack
对比Fis和webpack
Fis:设计理念: 资源加载器 + 资源表（构建工具级别支持资源表）
详细：没有打包在allinone文件中的，直接根据以来关系表按需加载。
它的本质是基于静态资源标记+动态解析静态资源表，在模板、js里边使用特殊的标记方法引用前端资源，构建的时候生成一张资源依赖表。使用 FIS3 作为编译工具的项目，可以将这张表提交给后端或者前端框架去运行时，根据组件使用情况来 【按需加载】资源或者资源所在的包，从而提升前端页面运行性能。所以不管是纯前端渲染（标记方法已经转换成浏览器能识别的了）还是后端（php、node、java）渲染，都很容易支持到，这样可以做到非常精细化的控制资源的按需加载。可以说fis真正做到了静态资源动态按需加载。
缺点：
自定义的一套标记语言，不能被浏览器直接接解析或者被社区流行的工具（browserify/babel）转换。比如fis依赖自家定制的mod.js来解析require()函数（即定位资源）以及资源base64内嵌语法__include()等。直接导致了fis无法和后来的强大的npm社区对接，大量的npm前端模块在fis用不了。
Webpack:设计理念：资源加载器（通过插件才能生成资源表）
详细：没有大包仔allinone文件中的，可能需要require.ensure这样子按需加载。
webpack 则没有资源表，直接就是通过加载器（loader）对静态资源打包合并。这货其实本质上是静态打包，生成chunk需要手动配置entry，虽然可以使用CommonsChunkPlugin、dll等插件辅助提取公共代码，以及【采用code split切割进行懒加载】，但这个粒度十分难把握，配置起来也比较困难（【fis是在代码中写依赖然后自动生成依赖关系和自动处理 懒加载（按需加载）】）
优点：
webpack现有的懒加载手段不完美，但是基本够用，主要是它直接支持commonjs规范的require语法，再配置babel等还可以直接解析ES6语法（当然，fis也可以通过插件支持ES6的），加上可以直接使用npm模块这一点，依托npm社区强大红利来搭建公司级公共组件化规范。
webpack配置简介
webpack配置主要由 出入口、加载器（loader）、插件构成
对于vue，我修改过的webpack配置主要有
- mock数据使用
- 多页面的history模式
- 多入口时【构建页面可配置】，【构建完毕自动访问页面可配置】
- 其他多入口相关的配置，具体看我这里的总结 – 公司vue项目总结
对于react，我写的项目配置比较繁杂的，具体看我这里总结 —— 公司React项目总结
架构及选型
架构比较总结
现在流行的架构有Vue 和 React, 对比两者：
相似之处：（和jquery开发的不同之处）
- 使用 Virtual DOM（Virtual DOM是一个映射真实DOM的JavaScript对象）
- 提供了响应式 (Reactive) 和组件化 (Composable) 的视图组件。（即都有组件化的开发思路）
- 将注意力集中保持在核心库，而将其他功能如路由和全局状态管理交给相关的库。（注意力集中在自身，路由、状态管理 交由其他库 ）
不同之处：
- Vue偏向于视图的开发、react偏向逻辑的开发（但整体来说我们发现表现类的组件远远多于逻辑类组件）
- react native已经比较成熟了，vue的weex还在积极发展
- 组件的重渲染react需要手动控制（shouldComponentUpdate），vue是自动控制的
- 路由库 和 状态管理库 Vue 的 都是由官方维护支持且与核心库同步更新的， react 由社区支持。
选型时要结合自身具体情况。
架构比较细节
运行时性能
React 和 Vue 都是非常快的，所以速度并不是在它们之中做选择的决定性因素。
优化：React:
在 React 应用中，当某个组件的状态发生变化时，它会以该组件为根，重新渲染整个组件子树。
如要避免不必要的子组件的重渲染，需要在【所有可能的地方】使用 PureComponent，或是手动实现 shouldComponentUpdate 方法。
使用时必须保证该组件的整个子树的渲染输出都是由该组件的 props 所决定的（就是说要保证此组件及其自组建可优化，否则会导致难以察觉的渲染结果不一致）。
综上react做优化是需要相当的心智负担的。
Vue:
在 Vue 应用中，组件的依赖是在渲染过程中自动追踪的，所以系统能精确知晓哪个组件确实需要被重渲染。— 自动渲染并且没有上述的子树问题限制。
总结：
组件的重渲染react需要手动控制，vue是自动控制的。Vue 的这个特点使得开发者不再需要考虑此类优化，从而能够更好地专注于应用本身。
HTML&CSS
JSX vs Templates
【React中基本一切都是JavaScript（html、js、甚至css）】
优势：
可以使用完整的编程语言 JavaScript 功能来构建你的视图页面。（JavaScript语法都能使用，js的相关工具也能使用，比如linting、类型检查、自动补全等）
【Vue 的整体思想是拥抱经典的 Web 技术（主要说的html模版），并在其上进行扩展。（也提供了渲染函数，甚至支持 JSX。然而，我们默认推荐的还是模板。）】
优势：
读写自然，容易上手，迁移老项目容易
总结：
我们可以把组件区分为两类：一类是偏视图表现的 (presentational)，一类则是偏逻辑的 (logical)。我们推荐在前者中使用模板，在后者中使用 JSX 或渲染函数。这两类组件的比例会根据应用类型的不同有所变化，但整体来说我们发现表现类的组件远远多于逻辑类组件。
组件作用域内的 CSS
CSS 作用域在 React 中是通过 CSS-in-JS 的方案实现的 (比如 styled-components、glamorous 和 emotion)。
在构建时将 CSS 提取到一个单独的样式表是支持的，一个关键问题就是需要权衡 bundle 的尺寸和运行时的开销。
vue也可以使用CSS-in-JS的方案，但是vue使用的是在 单文件组件（.vue文件中）中使用类似style的标签
规模
向上扩展：
Vue 和 React 都提供了强大的路由来应对大型应用。
重要差异：
Vue 的 路由库 和 状态管理库 都是由官方维护支持且与核心库同步更新的。
React 则是选择把这些问题交给社区维护，因此创建了一个更分散的生态系统。但相对的，React 的生态系统相比 Vue 更加繁荣。
（了解— vue的脚手架vue-cli其实挺好的；react的脚手架creat-react-app限制颇多，而限制是故意设计的）
向下扩展：
React 学习曲线陡峭，使用前需要学习构建系统，需要知道 JSX 和 ES2015语法
Vue 向上扩展好比 React 一样，Vue 向下扩展后就类似于 jQuery。
原生渲染
React Native 能使你用相同的组件模型编写有本地渲染能力的 APP (iOS 和 Android)。能同时跨多平台开发，对开发者是非常棒的。
vue的Weex 还在积极发展，成熟度也不能和 React Native 相抗衡。
另一个 Vue 的开发者们很快就会拥有的选项是 NativeScript，这是一个社区驱动的插件。
总结：
react native已经比较成熟了，vue的weex还在积极发展
Mobx
Mobx 在 React 社区很流行，实际上在 Vue 也采用了几乎相同的反应系统。在有限程度上，React + Mobx 也可以被认为是更繁琐的 Vue，所以如果你习惯组合使用它们，那么选择 Vue 会更合理。
移动端适配
抱歉，做移动端的需求不多，只是自己闲来阅读和总结了一些移动端的东西。
基础概念
布局视口：在手机上，视口与移动端浏览器屏幕宽度不再相关联，是完全独立的，这个浏览器厂商定的视口被称为布局视口。
视觉视口：视觉视口是用户正在看到的网页的区域，大小是屏幕中CSS像素的数量。
理想视口：布局视口明显对用户是不友好的，完全忽略了手机本身的尺寸。理想视口是网页用户最理想的宽度，用户进入页面的时候不需要缩放。
解决各种浏览器兼容问题的理想视口设置：<meta name="viewport" content="width=device-width,initial-scale=1">
设备像素比：
缩放程度为100%时，设备像素比：dpr = 设备像素（屏幕物理像素，单位pt） / CSS像素(单位px) —— 可以通过JS得到： window.devicePixelRatio
即：dpr = 屏幕横向设备像素 / 理想视口的宽
适配解决方案
Flexible的布局方案（根本是rem）
vw（viewport单位）来做移动端的适配问题。
Flexible承载的使命:
- 根据dpr的值来修改viewport实现1px的线
- 根据dpr的值来修改html的font-size，从而使用rem实现等比缩放
- 使用Hack手段用rem模拟vw特性
vw:
- 各终端下的适配问题 — 不同的终端，我们面对的屏幕分辨率、DPR、1px、2x图等一系列的问题。只不过解决这些问题不再是使用Hack手段来处理，而是直接使用原生的CSS技术来处理的。
- Retina屏的细节处理
100vw = 750px，即1vw = 7.5px
我司的移动端 以 浏览器默认字体大小16px（1rem === 16px）为准，算出设计稿中的尺寸对应的rem， 然后根据长平、宽平等计算出html的font-size达到适配效果
关于源码阅读
阅读源码是一种精神！不要听到别人说什么什么的源码就被吓倒了，淡定，试着分析分析，看的多了慢慢你就也能写别人口中的源码了。
去年花了2月把jQuery源码看了1遍半，虽然还记不住，不过看懂没问题。点这可看我注解
版本控制
不想多说，这是我曾经给公司其他员工做科普整理和使用的讲义。版本控制系统.pdf
终端命令
后边是我使用终端命令的方式，不要笑！不要笑！不要笑！重要的事情说三遍[微笑] - 这里
node
原谅我之前没有认真研究，一直是一边google查文档一边使用，不过你等着，我会回来的（后边会补充上详尽内容）。