前端开发知识点整理

Growth Front-End Knowledge Summary

前言: 本文主要是有关前端方面知识按照 XX 目前的认知进行的收集、归类、概括和整理,涵盖『前端理论』与『前端实践』两方面。本文会告诉你前端需要了解的知识大致有什么,看上去有很多,但具体你要学什么,还是要 follow your heart & follow your BOSS

初衷。写这篇文章主要有以下几个初衷:

  • 梳理知识体系。网上虽然有许多类似的内容,但每个人都有各自独特的思维方式,适合自己的才是最好的。
  • 探索不足之处。明确自己到底掌握了哪些,哪些本应掌握但还没有学习。
  • 完善公司的前端培训方向。前端技能培训的方向由懂前端、懂公司前端团队的人来设定最好不过了。
  • 希望借此激发大家的一点思考。我们都在路上,我不是成功的例子,我写下我的思考,希望借此激发大家的一点思考。
  • 一个梗。自 2012 年以来,我知乎上获赞最多的答案却是引用他人的答案……有点尴尬:《一名合格的前端工程师的知识结构是怎样的?》

目录

专业技能

前端理论

浏览器

  • 浏览器内核渲染原理
    • HTML 解析器
    • CSS 解析器
    • JavaScript 引擎
    • 渲染流程
      • 加载
      • 解析(确定结构、计算样式)
      • 构建 DOM 树、应用样式
      • 绘制
      • 回流
      • 重绘
  • 浏览器调试
    • 工具
      • F12
      • 扩展插件
      • 浏览器常用快捷键
    • 调试内容
      • 元素
        • 结构
        • 属性
      • 样式
      • 脚本
        • 日志
        • 断点
        • 事件
        • 变量监听
        • 调用堆栈
      • 性能
        • snapshot
        • 耗时
      • 网络请求
        • 模拟请求
        • 审查网络
        • 模拟网络环境
      • 内存
      • 本地存储信息
        • cookie
        • local storage
        • cache
    • 调试技巧
  • 浏览器事件
    • 常见事件
      • 鼠标事件
      • 表单元素事件
      • 键盘事件
      • 文档事件
      • CSS 事件
      • ……
    • 事件处理、添加、移除
  • 浏览器任务调度机制
    • micro queue
    • macro queue
  • 浏览器兼容性
    • 各平台浏览器的坑(家家有个难填的坑,有的坑深,有的坑浅)
      • 移动端浏览器
        • UC
        • Safari
        • 微信浏览器
        • 百度
        • ……
      • PC 端浏览器
        • Chrome
        • Firefox
        • IE
        • Edge
        • ……
      • 小程序
    • 不同浏览器内核差异
      • CSS 私有属性前缀(注:建议使用 postcss 自动化补全)
      • Polyfill
    • HTML、CSS、Javascript 特性支持度
      • MDN
      • Can I use ?
  • 常见问题
    • 请求跨域
    • iframe 跨域通信
    • 各种兼容性问题
    • 网页加载速度慢
    • 按钮点击没反应……

HTML

吃土小2叉:据说 HTML 和 CSS 一起学习体验最佳哦

  • 语法 & 语义
    • !DOCTYPE HTML 文档标准
    • head
      • meta 元数据标签
        • 网页描述
        • 设备描述
        • HTTP 请求描述
        • HTTP Client Hints
    • body
      • 装饰型标记(不推荐、部分已废弃)
      • 功能型标记
        • 无语义容器(div、span)
      • 用户交互(交互型标记)
        • 输入框
        • 选择器
        • 多选框
        • 单选框
        • 按钮
      • 数据可视化(展示型标记)
        • 定义列表
        • 无序列表
        • 表格
        • 结构化数据标记、微数据
        • 多媒体
          • 图片
          • 视频
          • 音频
        • SVG、Canvas
        • 文章(正文、摘要、段落、章节、前言、结语、引用)
  • 规范
    • HTML 代码规范
    • HTML 使用规范(标签嵌套规则)
      • 标签类型
  • 可访问性、无障碍体验
  • 常见问题
    • 图片空 src 导致页面加载两次
    • iframe 空 src 导致无限循环加载本页面

Alt text

上图据说是 HTML5 规范中关于 HTML 标签嵌套规则的示意图

CSS

吃土小2叉:用设计师的思维去理解 CSS,用程序员的思维去写 CSS

  • 语法(CSS 从入门到放弃)
    • 基本用法
    • 选择器
    • 媒体查询
    • 简写属性
    • 注释
    • 属性运算 calc()
  • 规范(编写可读性良好的 CSS)
    • 用例规范
      • 权限控制
      • 最佳实践
      • 不良习惯
    • 格式规范
      • 风格
      • 复用
      • BEM 规范
  • 逻辑特性(在 CSS / Less 中运用 OO 思想和设计模式)
    • 权重(优先级)
    • 作用域
    • 封装(mixins)
    • 组合(mixins+)
    • 扩展(:extend)
    • 继承(mixins)
    • CSS 变量、Less 变量
    • 模块化(import)
  • 视觉设计(单一状态设计)
    • 布局
      • 盒模型(高度、宽度、边框、外边距、内边距、溢出控制)
      • 定位方式
      • 层叠上下文(z-index)
      • display 类型(table、inline、inline-block、block、flex、grid)
      • 浮动
      • 伪元素::after、:before
    • 字体排印(厉害了 word 哥)
      • 字体(字体族、网络字体)
      • 文本(删除线、下划线、斜体、粗细、字号)
      • 段落(行高、缩进、断句方式、换行方式)
      • 对齐
      • 方向
    • 装饰(神说,要有光)
      • 颜色
      • 背景
      • 边框(border、outline)
      • 圆角
      • 阴影
      • 渐变
      • 透明度
      • 变形(旋转、缩放、矩阵变化)
  • 交互设计(多状态设计)
    • 动画(运动和静止是对立的统一)
      • 过渡效果
      • 动画关键帧
    • 反馈
      • active、checked 状态
    • 引导
      • 结合 Javascript
      • CSS 动画
    • 互动
      • hover 状态
  • 多设备设计
    • 响应式设计(多套代码,多种设备)
      • 媒体查询
    • 自适应设计(一套代码,多种设备)
      • 最小固定宽度布局
      • 百分比布局
      • 栅格布局、弹性布局
      • js + rem 方案(rpx)
  • 常见问题
    • 视觉还原度
    • 调试技巧
    • 属性“失效”问题
      • transition “失效”?
      • z-index “失效”?
    • 外边距合并
    • 边框 1px 问题
    • 垂直居中
    • 大屏幕 rem 小屏幕 px
    • 图片适配
    • 可维护性
      • 权重控制
      • 嵌套层级
      • 语义性
  • 扩展内容
    • 预处理器:Less、Sass
    • 后处理器:postcss
    • 小程序的 WXSS
    • Weex、RN 中的 CSS

JavaScript

吃土小2叉:至今还没看完一遍《JavaScript 高级程序设计》的我是该好好面壁思过了。

本段内容大量参考了:《The Modern JavaScript Tutorial》http://javascript.info/ ,推荐阅读。

  • JavaScript 标准
    • 严格模式
    • 兼容模式
  • 开发工具
    • IDE
    • 轻量编辑器
  • 基础语法
    • 数据类型
      • 基本数据类型 numberstringbooleannullundefinedobjectsymbol
      • 数据类型检测
      • 解构赋值
        • 数组
        • 对象
      • date 与时间
      • JSON
        • 格式说明
        • 序列化
        • 反序列化
      • 数组
        • 数组操作(增、删、改、遍历、复制)
        • 多维数组
    • 变量
      • 声明 varletconst
      • 声明提升
    • 作用域
    • 逻辑控制
      • 循环
      • 分支
      • 判断
    • 对象(基础部分)
      • 对象操作(增、删、改、查、复制)
      • Symbols
      • 类型转换
      • 垃圾回收机制
      • 对象方法中的 this
      • new
    • 函数
      • 函数默认值
      • 函数声明
      • 立即执行函数
      • 箭头函数
    • 运算符
      • 数值运算
      • 逻辑运算
    • 事件
      • 浏览器事件
      • 冒泡、捕获
      • 事件捕获
      • 浏览器默认行为
    • 文档
      • DOM 树
      • 节点
        • 节点类型
        • 节点标签
        • 节点内容
      • window 对象
    • DOM 操作
      • 元素节点(增、删、移、换、复制)
      • 元素属性(增、删、改、查)
      • 文本内容(增、删、改、查)
    • 网络请求
      • ajax(回调函数)
      • Promise
      • async、await
  • 深入细节
    • 对象、类、继承
      • 属性标记与属性描述
      • 原型、原型链
      • 继承
      • 属性定义
      • 对象混合
      • 类型检测
    • 数据类型
      • 基本类型
    • 函数进阶
      • 递归、调用堆栈
      • 闭包
      • 函数绑定、上下文
      • 剩余参数、扩展语法
      • 函数对象
      • 任务调度:定时器
      • 柯里化
      • 深入箭头函数
      • 函数式
    • 面向对象
    • 错误处理
      • 错误捕获
  • 代码质量
    • 注释
    • 相关工具
      • ESLint、JSLint
      • Standard.js
      • Prettify
      • 自动化测试工具:Jest、Mocha
    • 用例规范
      • 最佳实践
      • 不良习惯
    • 格式规范
      • 风格
  • 正则表达式
    • 普通字符、转义字符
    • 元字符
    • 字符类
    • 分支条件
    • 分组
    • 反义
    • 贪婪与懒惰
    • 后向引用
    • ……

编程通用

软件工程的核心就是管理复杂度 —— 《代码大全 2》

推荐阅读:来自法海@淘宝前端团队《从达标到卓越 —— API 设计之道》

  • 达标(语法、词法)
    • 正确拼写
    • 准确用词
    • 注意单复数
    • 不要搞错词性
    • 处理缩写
    • 用对时态和语态
  • 熟练(语义、可用性)
    • 单一职责
    • 避免副作用
    • 代码一致性
    • 合理设计函数参数
    • 合理运用函数重载
    • 使返回值可预期
    • 固话术语表
    • 遵循一致的代码风格
  • 卓越(系统性、大局观)
    • 版本控制
    • 确保向下兼容
    • 设计扩展机制(易于扩展)
    • 控制 API 的抽象级别
    • 设计模式
    • 注释
    • DRY
    • 编码规范
    • 解耦
    • 复杂度控制

SEO & 数据统计 & 数据分析

吃土小2叉:尽人事,听天命(天者,用户也)

  • SEO
    • 影响因素
      • 相关性
        • title
        • 关键词密度
      • 权威性
        • 外链
        • 内链
        • 域名年限
        • 网站收录
        • 安全性
      • 用户体验
        • 广告
        • 加载速度
        • 内容质量:内容真实性、内容原创性、内容有益性
    • 不良行为
      • 堆叠关键词
      • 抄袭、作弊
      • 大量低价值外链
      • 广告、木马、病毒 -数据统计
    • 工具
      • 统计、埋点工具:Google Analytics、百度统计、Piwik……
      • 站长工具:Google Webmaster 、百度站长工具
      • 其他工具:百度指数、SEO 各项指标助手工具……
  • 数据分析
    • 工具
      • 同数据统计工具
      • 脑子是个好东西
    • 分析方法
      • 归因、排查
      • 细分
        • 来源、渠道
        • 用户属性
          • 人口统计学
        • 用户行为
          • 站内搜索关键词
          • 自定义事件(埋点事件)
          • 浏览频率、时间、跳出页
          • 访问内容
          • 访问漏斗
        • 站点属性
      • 对比
        • 时间维度
        • 统计指标维度
    • 目标设置
      • 转化路径
      • 转化目标
      • 转化价值

网络基础

此处是不是又要出现,经典问题:当你在浏览器输入 URL 并回车(非单页应用的传统网站),直到你看见这个页面,此时经历了哪些过程(略去浏览器渲染环节)。

  • TCP / IP
    • HTTP
      • 请求
        • 请求头
        • 请求正文
      • 响应
        • HTTP 状态码(2xx、3xx、4xx、5xx)
        • 响应头
        • 响应正文
      • 过程:三次握手
    • HTTP2
    • HTTPS
    • Web Socket
    • CORS
    • Session、Cookie
    • RESTful / RPC
  • DNS 、域名、IP
    • 域名劫持
    • 内网、公网地址段
  • 缓存
    • 服务端缓存
    • 客户端缓存
  • 常用工具
    • F12 Network Panel
    • Advanced REST client
    • EditThisCookie
    • Wireshark
    • Fiddler、Charles
  • 常见问题
    • HTTP 迁移到 HTTPS 站点部署问题
      • HTTPS 证书部署
        • TLS 版本问题
        • 证书作用域(是否包含子域名)
        • 证书、秘钥配置文件
      • 资源加载同协议
        • error 级
          • 外部 JavaScript 加载
          • iframe
        • warning 级
          • img
          • CSS
      • 网络请求同协议
        • error
          • ajax
          • jsonp

交叉领域理论

吃土小2叉:学习交叉领域知识的一个很朴实的目的 —— 掌握如何甩锅

产品设计相关

吃土小2叉:学会优雅地质疑设计 => 给用户更好的体验

  • 与设计师的沟通、协作
  • 设计理念 => 用户体验
    • 一致性
    • 可用性
    • 易用性
    • 反馈
  • 提升审美
    • 单反穷三代 // 单身狗 XX:也许学好摄影就能追到女神了呢?
    • 竞品分析 // 知己知彼,重视对手
  • 常用工具

后端基础

吃土小2叉:只要把这篇文章《系统设计入门》上面你不认识的术语弄懂就可以了 (迷之微笑)

XX 的观点:时刻谨记编程语言只是一种工具,分别有不同适用的场景罢了。理性、客观、结合实际。

  • 与后端开发工程师的沟通、协作
    • 明确分工
    • 文档先行
    • mock 数据
  • 简单了解一门后端语言 // XX 注:如果你已经自己搭建了个人博客站点,后端语言的语法层面足够了。
  • 了解前端路由与后端路由的区别
  • 简单应用数据库(MySQL)
    • 增、删、改、查
    • 备份、导出
  • 了解作用与概念
    • GraphQL
    • Nginx
    • Redis
    • 负载均衡
    • CDN
    • 数据库主从备份
  • 计算机相关基础知识 // 有时间多重温(预习)重温(预习)
    • 数据库
    • 操作系统
    • 编译原理
    • 离散数学
    • 数字逻辑

前端实践

实践是检验真理的唯一标准,在此引用 Vue.js 作者尤雨溪的一段话:

技术方案都是先有问题再有思路同时伴随着取舍。在选择衡量技术的时候,尽量去思考这个技术背后是在解决什么问题,它做了怎样的取舍。这样一方面可以帮助我们更好的理解和使用这些技术,也为以后哪天你遇到业务中的特殊情况,需要自己做方案的时候打好基础。

解决实际问题

Learn from you mistakes.

吃土小2叉:写下这篇文章的时候恰逢今年高考,很感谢高一的英语老师当时给我们布置的一个作业:整理考试错题集。因为经历过太多次,同样类型的题目这次错,下次仍然错。而我又是一个比较较真的人,每次整理错题的时候,不单单只记录做错的问题和答案,还会去分析这里的考点,所涉及的知识点,去试着换位思考如果我是出题人,会怎么出这道题,考哪些知识点可以坑一下考生。而这一过程,又有着考试做错题的心理愧疚感,记忆会特别深刻。另一方面,在复习阶段,也可以更具有针对性地复习,为自己减压。要尽量把大脑当成 CPU 来用,或者倒排索引,而非硬盘、数据库。

Learn from your practice.

而在编程过程中,也是比较接近。我们可以记录下自己犯过的错误,不良的编码案例。同时,我们也可以像经常收集一些名人名言、固定搭配等写作套路一样,去整理、收集自己在开发过程中的最佳实践。当然若是有时间再去思考、反思、优化,那就更好了。

Learn from your worry & adversity.

另外,抱着积极的态度强大的内心去面对开发过程中的任何困惑、困境,都是助力快速成长的好机会。

前阵子我在 GitHub 上也开了一个项目,专门记录、收集我最近在前端开发过程中遇到的一些问题,有已经解决的,也有仍待解决的。

https://github.com/xunge0613/front-end-practice-collections

目前整理的已解决问题有:

仍待解决的问题:

  • 如何优雅地监听元素高度变化?
  • 移动端 banner 轮播图自适应的各种坑

当然我也简单写了一些方法论,包括:

后续我也会不断完善这一块内容。重点是:形成一套属于自己的最佳实践经验库。

学习型项目

这一部分内容更推荐大家关注 Phodal 大神的 Growth 系列

https://github.com/phodal/growth

而我给准备入门前端的新手的建议是:

拥有一个完全属于自己的博客、域名、网站、服务器,并每周固定更新博客文章、每年为博客更新一次主题。

前端工程

勿忘自己的 title:前端工程师

以下引用张云龙 dalao 的文章:前端工程 —— 基础篇

第一阶段:库/框架选型 第二阶段:简单构建优化 第三阶段:JS/CSS模块化开发 第四阶段:组件化开发与资源管理

由于先天缺陷,前端相比其他软件开发,在基础架构上更加迫切的需要组件化开发和资源管理,而解决资源管理的方法其实一点也不复杂:

一个通用的资源表生成工具 + 基于表的资源加载框架

第一阶段:框架应用

吃土小2叉:只要是一个文档友好的框架,遇到不会的问题,去翻翻文档,如果解决不了,再去认真翻一次。因此,第一阶段,亦可认为是:面向文档编程

此处建议再回忆一下刚才提及的尤大的话。

以下是我个人的框架/库应用路线:

jQuery => jQuery + artTemplate => Vue.js + lodash => Vue.js 全家桶

  • jQuery // 此处参考张鑫旭的 jQuery 1.4 中文文档
    • 核心
      • 对象访问
      • 数据缓存
      • 队列控制
      • 插件机制
      • 多库共存
    • 事件
      • 页面载入
      • 事件处理
      • 事件委托
      • 事件切换
      • 常用事件
        • 鼠标事件(click、dbclick、hover、mouse*……)
        • 键盘事件(key*……)
        • 表单事件(blur、change、focus、submit、select)
        • 浏览器事件(error、resize、scroll)
        • 触摸事件(touch*……)
    • 选择器
      • 基本
      • 组合
      • 伪类
      • 内容
      • 可见性
      • 属性
      • 表单
    • 筛选器
      • 过滤
      • 查找
      • 串联
    • CSS
      • CSS
      • 位置
      • 尺寸
    • DOM 操作
      • 元素节点(增、删、移、换、复制)
      • 元素属性(增、删、改、查)
      • 文本内容(增、删、改、查)
    • 网络请求
      • Ajax
      • when
      • deferred
    • 特效
      • 基本(显示、隐藏)
      • 滑动
      • 淡入淡出
      • 自定义动画控制
    • 辅助工具(类似于 lodash)
      • 数组、对象操作
      • 函数操作
      • 字符串操作
      • 浏览器及特性检测
      • 类型检测
      • JSON 序列化
  • artTemplate
    • 模板引擎
  • Vue.js
    • MVVM 思想
    • 声明式渲染
    • 条件与循环
    • 处理用户输入
    • 数据绑定、响应式数据
    • 组件化应用构建
      • 组件间通信
  • lodash.js // 提供各种 helper 方法,专注于数据处理
    • 数据类型
      • 数组
      • 集合
      • 日期
      • 函数
      • 数值
      • 对象
      • 字符串
    • 语言特性
      • 类型检测
      • 类型比较
      • 复制
    • 数学运算
    • 辅助工具

XX:

  • 学你会用 artTemplate 以后,会发现 Vue.js 很容易上手
  • 当你学会 Vue.js 以后,你会发现小程序真的很容易上手

第二阶段:简单自动构建优化

专注业务开发

  • 工具
    • Grunt
    • Gulp
  • 预处理
    • Less
    • Babel
    • TypeScript
  • 后处理
    • PostCSS
  • 校验
    • ESLint
  • 压缩
    • 代码
    • 图片
  • 合并
  • 打包
  • 自动化测试
  • mock 接口调试

第三阶段:JS/CSS模块化开发

张云龙:分治、分治、分治

  • AMD
  • CommonJS
  • UMD
  • ES6 Module
  • ……

第四阶段:组件化开发与资源管理

核心目的:提高开发效率 & 兼顾运行性能

  • 分治、解耦、自由组合、就近维护
  • Vue.js 组件化开发
    • 抽象业务逻辑组件
      • 组合基础 UI 组件形成业务组件
      • 独立编写业务相关组件
      • ……
    • 定制基础 UI 组件库
      • 轮播图组件
      • 弹窗组件
      • ……
  • 资源管理

项目技术选型

理性、客观、避免偏见

  • 预计投入
    • 开发资源
      • 时间
      • 人手
      • 技术储备
    • 项目资源
      • 沟通成本
      • 设计文档、功能文档、产品原型
      • 后端接口文档
      • 项目排期
    • 产品资源
      • 用户群体
        • 浏览器兼容性
        • SEO 问题
  • 期望回报
    • 开发人员自我成长
    • 公司技术栈
    • 开发效率
    • 可维护性
    • 性能、稳定性
    • 易于测试
    • 易于把控项目周期
  • 应急预案
    • 兼容方案
    • 回退方案
    • A / B Test
    • 渐进增强
    • Plan B

造轮子

要么站在巨人的肩膀上,要么自己成为巨人

未完待续……

  • UI 组件库
  • 前端工具
  • 前端微服务
  • 前端框架
    • (以下内容是 XX 的 YY 内容)
    • 学习优秀框架源码
    • 仿写核心内容
    • 掌握山寨一个框架的套路
    • 发现问题
    • 具备扎实的前端基础 + 运气 + 灵感
    • 解决问题

版本规划

本文会在 GitHub 上持续维护,欢迎大家提 issue ~

地址是:https://github.com/xunge0613/front-end-growth/blob/master/tech-growth/growth-front-end-summary.md

v x.x.x

  • 更新 造轮子
  • 考虑翻译成英文?
  • 加入重要性评分功能
    • 引导目前阶段应该掌握哪些
    • 分为:初级、中级、高级

v 0.0.3 内容迭代

  • 更新 编程通用
    • 条目更新
  • 更新 JavaScript
  • 更新 前端实践
    • 新增引导语
  • 更新支付宝图标、微信图标……

===== 当前版本分割线 =====


v 0.0.2 内容迭代

  • 新增 后端基础
  • 新增 前端工程 第一阶段 jQuery、Vue.js 介绍
  • 新增 常见问题
  • 更新 前言
  • 更新 网络基础
  • 更新 学习型项目

致谢

  1. 前端工程 —— 基础篇 by 张云龙
  2. 从达标到卓越 —— API 设计之道 by 法海@淘宝前端团队
  3. The Modern JavaScript Tutorial by Ilya Kantor
  4. jQuery 1.4 中文文档 by 张鑫旭
  5. MDN Web 开发 // 这里有个小彩蛋,这个页面右上角有某 XX

联系方式

欢迎联系我讨论本文的不足、问题或者意见。

可以在我的 GitHub 主页上找到我的联系方式

亦可关注我的微信公众号:清风迅来

清风迅来

结语

作为一个老菜鸟,我只是知识的搬运工

本文大多讨论的是有哪些知识点(what),至于如何学习与应用这些知识点(how & why),敬请期待我之后的一系列文章,目前已完成一些雏形,仅供试阅:

感谢您一路看到这里,欢迎点击阅读原文在我的博客上进行留言一同探讨。(小透明表示公众号至今未开通留言功能……)

若有帮助,尽情打赏!^_^

ps: 好像图片有点大=。=

如果有帮助,欢迎打赏~如果有帮助,欢迎打赏~

许可

MIT

TECH × 大学路 第二期小结(和尤大合影了!)

内心非常excited


上线了组织的一场小型技术交流会,地点就在大学路,真的离公司好近好近好近。(听完讲座还可以回公司加个班,完美)
全英文的演讲非常有趣(非常庆幸自己最近沉迷翻译技术文)
特地早到坐在最前排,近距离和尤大接触还合照了~ 迷弟心愿达成√

下面说说技术小结,毕竟全英文演讲,很可能我理解错了哈哈哈哈,如有错误望指正~
这次有三个演讲,第一个演讲是一个德国小哥,聊了聊V8引擎的工作原理,包括JS API 调用后经历哪些过程(例如:console.log()),pre-parse 和 full-parse 的区别,以及如何利用立即执行函数提升性能(避免 pre-parse?)?

另外花了较多篇幅讲了内存分配,并提到几个优化内存分配的方法或者说一些避免额外内存开销的原则:

比如:同一类型对象,应该保持相同的属性,避免不同属性:

//  good
a.prop1;
b.prop1;

// bad: extra memory allocation for that
a.prop1;
b.prop1, b.prop2;

另外还介绍了几种不同数据结构的内存使用量,包括对象,数组,也提到了在数组中,尽量保持数组元素类型一致,可以优化内存分配。

原始例子:[1,2,3],3个基本类型,假设占据3单位内存

反面例子:[1,2,”abc”],在内存中,此处1,2会被隐式转为 { num : 1 },{ num : 2 },不再是基本类型而是复杂类型?而 “abc” 此时同样也是引用类型。这样会大大增加内存的开销。

so,简而言之就是涨姿势了。

 

第二位演讲者是strikingly的创始人郭达峰,主要议题是介绍了几次 react conf 的心得体会。

2015 React Conf

  • flux,flux,flux,flux,flux; // 大会重点讨论 flux
  • Redux;  // 有人提出了 redux
    • hotreload
    • time travel
    • functional
  • css in js;
  • GraphQL;
  • React as the UI virtual machines.

2016 React Conf

  • redux,redux,redux,redux,redux; // 今年轮到 redux 成了焦点
  • react native; // 有人提出 RN
  • more GraphQL // 更多的人讨论 GraphQL

2017 React Conf

  • performance:
    • react fiber
      •  reconciliation
      • Priority Scheduling 优先级调度
    • react 16
    • SSR
    • streaming,rakt(leaf,preserve)
  • pollishing tools:
    • create-react-app
    • Jest // 2年前一般般的测试工具,现在咸鱼翻身了:)
      • fast,
      • snapshot testing,
      • nice interactive CLI
  • js fatigue
  • mature community
  • AOT (gatsby, svelte,prepack)
    • less runtime cost,
    • less framework,
    • more build time cost

以及提到未来的js可能的方向:

in other languages

  • Reason:OCaml
  • Closure script:Closure
  • Web Assembly

XX注:关于 React Fiber ,突然觉得很像是平时开发团队的项目管理模式。每周五分配任务A、任务B、任务C,按优先级一个个完成。假如周一还在做任务A的时候,突然来了一个临时的老板级紧急需求任务D,那么就先把任务D安排到任务A前面……

最后是尤大…前端界的颜值担当
首先介绍了Vue 受哪些启发

  • Braid
  • web components
  • Ractive

然后是vue单文件组件实现原理,

先讲了 template,script,style 分别是如何解析,然后介绍了这三者是如何合在一起构成一个组件的。

另外提到了 hot reload 的注意事项,script 层面由于 state 的问题,需要整个component 全部 reload,避免副作用?

最后还提及一个等式:

Standard source format + extension compilation pipeline = evolution with less churn…

后面就是问答环节,印象比较深的一个按业务级切分文件,某个业务涉及到的文件(style,js,template,lib)组织在一起

尤大也提到希望有一个比 Vuex 或者 Redux 更轻量的状态管理工具?

另外尤大又提到了,技术方案,必须要结合实际问题,结合真实场景。

引用一下前几天尤大的知乎 live 的总结:

总结一下吧,我们聊了很多东西,可能比较杂,但我希望大家发现其中一些共性的东西:技术方案都是先有问题,再有思路,同时伴随着取舍。在选择衡量技术的时候,尽量去思考这个技术背后是在解决什么问题,它做了怎样的取舍。这样一方面可以帮助我们更好的理解和使用这些技术,也为以后哪天你遇到业务中的特殊情况,需要自己做方案的时候打好基础。

以上,可能有一些内容理解有误~ 望大家指正哈~ 多谢~ ……

最后再次感谢strikingly这么棒的一次分享活动,干货满满。

其实我还是蛮期待平时可以多交流交流, 大神就在离公司那么近的地方~~~

吃土小2叉

2017年6月3日21:31:26

前端开发实习生培养体系的探索:前端开发实习生织梦计划

前端开发实习生培养体系的探索:前端开发实习生织梦计划 v 0.1.0

谨以此名称『织梦』致敬 15 年前在初中第一次接触“前端”时用的编辑器: Dreamweaver

前言:

由于意识到目前的前端团队趋于稳定,可以适当加入一些实习生为团队注入活力。于是这段时间主动积累了一些相关经验,决定就前端技术团队的实习生培养这一主题,进行概念梳理以及雏形规划,顺便文末整理了一些优质学习资料和学习社群。另外,受限于 XX 的前端水平只有中级左右,文中对知识体系的整理可能不够深入和全面,也欢迎大家提提建议!

XX 的价值观 —— 80%+ 完美主义:当意识到重要性的时候,就应该充分利用已有资源,做到当前迭代的最好状态,或者至少是最好状态的 80%

强烈推荐: 姬光大佬的 gitchat《怎样实习才能成长最快》,非常感谢姬光大佬的这篇文章

注意:

此版本未经过任何实践!有待验证,仅供参考。

此版本未经过任何实践!有待验证,仅供参考。

此版本未经过任何实践!有待验证,仅供参考。

设定

定位(角色)、要求(输入)、愿景(输出)

以某 MMORPG 游戏为参考系,结合实习生系统(实习荣耀??),分别描述主要角色的定位、要求(输入)、愿景(输出)

尝试站在不同角色,不同角度思考各种问题,并简要概括

公司

定位:游戏世界

要求:

  • 实习薪资、下午茶(补给、金币、回血、回蓝)
  • 提供办公设备(游戏装备)
  • 公司氛围(buff、赠送 VIP 会员)
  • 公司文化(mutation @elona)
  • 公司理念、愿景(我司:减法新生活~)

愿景:

  • 实习生 => 公司
    • 树立、传播公司良好形象
    • 公司文化的传承
  • 公司 => 实习生
    • 公司文化的影响
    • 物质

业务

定位:游戏任务

要求:

  • 安排合适的业务任务(游戏主线任务)
  • 鼓励发现、提出业务问题(游戏支线任务)

愿景:

  • 实习生 => 业务
    • 提出业务的改进意见
    • 不强求解决业务问题,但如果能,再好不过。
  • 业务 => 实习生
    • 了解公司业务

团队

定位:NPCs、可爱的小姐姐们、帅气的大叔们(雾

要求:

  • 交流(提供任务线索)
  • 知识点、概念指点(buff、治疗)
  • 学习方向引导(buff、T)

愿景:

  • 实习生 => 团队
    • 沉淀团队技术、整理文档(经验包)
    • 储备新鲜血液、给团队注入活力(欢迎新 dalao……)
    • 打造技术学习小社区(战队、公会)
  • 团队 => 实习生
    • 熟悉团队开发模式(通用技能)
    • 团队技术知识库 wiki(各类技能书、经验包)

导师

定位:新手村村民(头上带问号的?王者农药主界面右下角的妲己?)

要求:

  • 理性维度
    • 技术指导、方法指导(讲清楚的程度、通通透透)
    • 善于观察(了解实习生的长处与短板)
    • 客观评估:对事不对人
    • 代价:额外占用时间(蛤?-1s)
  • 感性维度
    • 真诚待人
    • 认真负责
    • 谦虚谨慎
    • 乐于助人
    • 充分沟通
    • 忍耐能力

愿景:

  • 实习生 => 导师:
    • 成就感
    • 教学相长:基础知识梳理、深入理解、剖析、总结(经验包)
    • 沟通能力(带团能力)
    • 团队贡献积分(DKP)
  • 导师 => 实习生
    • 个人成长
      • 知识、技能(经验、技能)
      • 学习方向、职业规划(职业进阶路线)
    • 人脉(游戏好友)
    • 激励(buff)
    • 评估(战斗力估算?游戏解说???)

实习生

XX 注:人无完人,对于小公司而言,千里马难觅。要善于挖掘实习生的亮点,借助团队这个小社区引导实习生各方面成长。

定位:勇者

要求:

  • 理性维度 (能力 ability)
    • 学习能力
      • 知识记录、梳理、总结、抽象
      • 学习方法
      • 学习态度
    • 解决问题能力
      • 提问技巧
      • 思考、针对性练习、反思
    • 自我管理 & 效率
      • 碎片时间
      • 专注
      • 能量管理
    • 业务能力
      • 负责、谨慎、细心
  • 感性维度(特质 traits)
    • 心态、自信、耐心、不浮躁
    • 认真、积极、主动
    • 沟通能力
    • 友善、虚心、正直

愿景:

  • 实习生 A => 实习生 B
    • 竞争(排行榜)
    • 协作(队友、基友)
  • 实习生 A <=> 实习生 A
    • 个人成长(经验、技能、职业进阶选择)
    • 个人经历(成就、称号)

监督人

定位:新手村村长(隐藏 BOSS?大龙???)

要求:

  • 理性维度
    • 中立、客观
    • 观察力
  • 感性维度
    • 包容但不偏袒

愿景

  • ???

方案

总共招 1~2 个实习生

人员安排

1 监督人: XX 1 导师:老员工(2 年+经验) 1~2 实习生

实习生任务列表

师傅领进门,修行靠个人

注:实际安排的任务因人而异,可选择性增加或加强……:)

任务标准:SMART 任务 + 主动汇报

  • 主动汇报
    • 每日日报:产出(工作内容)、收获(知识)
      • 主动、认真
      • 审视、自省、回顾
      • 规范
    • 每周周报
      • 一周总结
  • SMART 任务
    • 【SMART】
  • 隐藏任务
    • GitHub
      • 鼓励分享、鼓励创新

任务内容

  • 个人成长线(高经验值主线)
    • 综合
      • 【SMART】博客文章(每周一篇)
      • 优秀源码学习
        • Bootstrap
        • jQuery
        • Element UI
        • Vue.js、lodash
    • 实践
      • 学习型项目
        • 【SMART】phodal growth 系列
        • 【SMART】导师自定义任务
    • 理论
      • 通用技能
        • 《暗时间》
        • 《On Managing Yourself 自我发现与重塑》
        • ……
      • 专业技能
        • 相关工具
        • 推荐书单
        • 编程基础
          • 软件构建
            • 《代码大全 2》
          • 算法
            • 【SMART】leetcode 刷题
          • 设计模式
            • 《Head First 设计模式》
          • 编码规范
            • 迭代 wiki 的“编码规范”
        • 前端理论
          • HTML、CSS、Javascript
            • 《CSS 揭秘》、《Javascript 高级程序设计》
            • 【SMART】freecodecamp、codewar 练习题
            • MDN 文档
          • Vue.js
            • Vue.js 官方文档
          • 前端工程、组件化、前端服务化
      • 前端应用
        • 团队相关
        • 业务相关项目
          • 根据实习生实际情况,安排合适的任务量、任务复杂度
  • 团队贡献线(高 DKP 支线)
    • 综合
      • 协作
        • 与前端
        • 与后端
        • 与测试
        • 与设计师
        • 与产品
    • 理论
      • 更新团队知识库 wiki
        • 维护团队插件、组件说明文档
        • 经验分享、bug 记录……
      • 撰写团队技术博客文章
      • 参与每周前端组周会
    • 实践
      • 学习型项目(团队 wiki 站点、团队技术博客站点维护迭代等)
  • 业务线(高 DKP 支线)
    • 综合
      • 发现、提出业务问题,尝试解决
    • 实践
      • 【SMART】解决导师布置的业务需求
    • 理论
      • 梳理业务流程图
      • 梳理网站功能

导师任务列表

  • 传道
    • 前端的 what、why、how
    • 开阔技术视野
    • 解决问题的套路
    • 愿景(vision)
  • 授业
    • 介绍团队
    • 工作流程
    • 学习方法
    • 文档说明
    • 安排工作
  • 解惑
    • 告知所以然
    • (若导师无法解答,很正常,毕竟闻道有先后、术业有专攻。重点在于)
  • 评估
    • 认真审查实习生的 ① 日报 ② 周报 ③ 文档、代码、文章并积极、客观反馈
    • 定期与实习生交流
      • 主动挖掘实习生存在的问题,予以引导
      • 主动挖掘实习生的长处,并加以培养
  • 激励
    • 适当的团队活动
    • 正面引导
    • 不要吝啬表扬
  • 负责
    • 对实习生的代码负责
      • Code Review
      • 追踪代码质量、产品上线后的质量
      • 跟踪项目进度,把控风险
    • 对实习生负责
      • 真诚
      • 正面引导
    • 对自己负责
      • 不断提升自己的姿势水平
      • 共同成长

举例

背景

1 个本科大三暑期实习生,2 个月的工作时长,每周来 4 天。

已知

  • 实习生
    • 协作 专业能力 无工作经历
    • 专业能力 能使用 jQuery 较为熟练地写带有简单交互的静态页面
    • 专业能力 只照官网写过 Vue.js demo,没有写过具体项目
    • 协作 代码不规范
    • 专业能力 会一些 PHP
    • 通用能力 性格偏外向、求知欲强、不够细心、略微有点浮躁
  • 任务痛点
    • 团队 团队编码规范不完善、未统一
    • 团队 团队的知识库不完善
      • 缺少组件库说明文档(Vue.js 组件库,总共约 20 个 UI 组件)
      • 缺少公共方法说明文档
    • 团队 项目代码注释不完善
    • 业务 偶尔有紧急的市场活动小需求插入
    • 公司 培养储备人才

方案

注:方案中,专业能力 表示此任务对于 专业能力 有要求或能带来提高,即任务目的(why)

第一个月

  • 整理团队组件库使用说明文档(每周至少完成 1+ 个组件说明文档;最坏情况在指导下可能需要 24 天,熟悉后预计工时 0.52 天)
    • 专业能力 阅读组件源码
    • => 通用能力 学习能力 技术视野 导师指导(最坏情况在指导下可能需要 12 天,熟悉后预计工时 00.5 天)
    • 代码规范 专业能力找出源码中难以阅读、理解的代码块
    • 文档沉淀 代码规范 编写说明文档
    • => 通用能力 学习能力 技术视野 导师审查文档 => 反馈
  • 应对紧急的市场活动页面(预计工时 1 天)
    • 业务需求 编写静态页面
    • => 通用能力 学习能力 技术视野 导师审查代码 => 反馈
  • 【待定】团队知识库站点搭建(预计总工期 2 个月,每周安排 1~2 个工作日开发)
    • 团队 专业能力 代码编写
  • 阅读推荐资料
    • 专业能力 Vue.js 官方文档阅读、《某书》
    • => 通用能力 学习能力 导师指导答疑
  • 每天日报 (预计工时 0.5~1 小时,合计 0.5 天)
    • 通用能力 专业能力 知识收获
    • 通用能力 专业能力 工作内容
  • 每周周报(预计工时 1~2 小时,合计 0.25 天)
    • 通用能力``专业能力 知识收获
    • 通用能力 专业能力 工作内容

未完待续……

推荐资料

以下仅收集 XX 读过的资料或者经常参与讨论的社群。也欢迎大家推荐~

书单

通用能力

《暗时间》、《On Managing Yourself 自我发现与重塑》

专业能力

《代码大全 2》 《CSS 揭秘》 《Javascript 高级程序设计》 《Head First 设计模式》

博客

学习社群

引用庄表伟大佬的一段话……

求知欲不能教授 但可传染 学习能力无从教 却能修炼

  • 群(吹水少、禁广告)
    • 豪情大佬 QQ 群
    • 前端之巅微信群
  • 组织
  • gitchat 、知乎 live 活跃大神
    • 专业技能
      • 姬光、hax、小爝、justjavac、phodal……
    • 通用技能
      • Lachel、Warfalcon……
  • 小密圈
    • T 型学院
    • 前端早读课
    • 小胡子哥
  • 微信公众号
    • 前端早读课(起床第一件事……看前端早读课……肯定有更新……)
    • 前端大全
    • ……
  • github 学习项目

参考资料

  • 强烈推荐:姬光大佬 gitchat《怎样实习才能成长最快》
  • 姬光大佬 gitchat《老司机导师陪你聊聊带新人的那些“套路”》
  • ZoomQuite 大佬 gitchat 《初学者如何通过技术社区加速成长?》
  • 刘未鹏 《暗时间》

版本规划

本文和上次写的《前端开发负责人修炼指北》一样,会在 GitHub 上持续维护,欢迎大家提 issue ~

本文地址是:https://github.com/xunge0613/front-end-growth/blob/master/team-growth/weave-dreams-for-interns.md

v 0.1.1

  • 完善举例
  • 导师任务优化
    • 加入【SMART】 类型任务
  • 完善监督人模块内容
    • 增加监督人任务
    • 完善监督人描述
  • 推荐资料更新
  • 考虑是否要在后续版本更新“公司”、“业务”相关内容

结语

v 0.1.0 版本主要是理论的规划,由于自己 80%+ 的完美主义特质,希望能借此规划团队的实习生体系,并不断优化,对团队的实习生负责,对团队负责。也希望这篇文章能给大家带来一些思考。接下来会在实践的过程中思考、反思,不断迭代该计划。

最后,以《云图》全书最后一段结尾:

“要和人性的九头蛇进行斗争的人必须以经受巨大的痛苦为代价,而且他的家人必须跟他一起为此付出代价!不见棺材不落泪,你要明白,你生命的价值不过像是无边无垠的海洋里的一滴水!”

“但是如果没有众多的水滴,哪会有海洋呢?” *“What is any ocean but a multitude of drops?” *

鸣谢

感谢姬光大佬的两篇文章…… 强烈建议大家读一读……

感谢提出宝贵意见的大伙伴们~

感谢大家抽出时间来围观我这篇文章……

感谢马克飞象这款性价比超高的记录工具~

最后,感谢自己~

如果有帮助,欢迎打赏~

【译】解密 Quantum:现代浏览器引擎的构建之道

解密 Quantum:现代浏览器引擎的构建之道

2016 年 10 月,Mozilla 公布了 Quantum 项目 —— 旨在开创下一代浏览器引擎。现在这一项目已然步入正轨。实际上,我们在上个月刚更新的 Firefox 53 中首次包含了 Quantum 的部分核心代码

但是,我们意识到对于那些不从事浏览器开发的人来说(而且是大多数人),很难明白这些改动对于 Firefox 的重大意义。毕竟,许多改动对于用户来说是不可见的。

意识到这点后,我们开始撰写一系列博客文章来深度解读 Quantum 项目正在做什么。我们希望这一系列的文章能够帮助大家理解 Firefox 的工作原理,以及 Firefox 是如何打造一款下一代浏览器引擎,从而更好地利用现代计算机的硬件性能。

作为这系列文章的第一篇,最好还是先说明一下 Quantum 正在改变哪些核心内容。

浏览器引擎什么?它的工作原理又是什么?

那么,就从头开始说起吧。

Web 浏览器是一种软件,它首先加载文件(通常这些文件来自于远程服务器),然后在本地显示这些文件,并且允许用户交互。

Quantum 是项目的代号,Mozilla 启动这个项目是为了大幅度升级 Firefox 浏览器的某个模块,这个模块决定了浏览器如何根据远程文件将网页显示给用户。这一模块的行业术语叫“浏览器引擎”,如果没有浏览器引擎,用户就只能看看网站源代码而不能浏览网站了。Firefox 的浏览器引擎叫 Gecko。

可以简单地把浏览器引擎看作一个黑盒(有点类似于电视机),灌入数据后由黑盒来决定展示在屏幕上的数据形态。现在的问题是:浏览器引擎是如何呈现页面的?它是通过哪些步骤将数据转化为我们所看见的网页?

网页数据通常有许多类型,但总的来说可以划分为三大类:

  • 用于描述网页结构的代码
  • 用于提供样式的代码,描述了网页结构的视觉外观
  • 用于控制浏览器行为的脚本代码,包括:计算、人机互动以及修改已初始化的网页结构和样式。

浏览器引擎将页面结构和样式结合从而在屏幕上渲染出网页,同时确定可以互动的内容。

这一切要从网页结构说起。浏览器会根据给定的地址去加载一个网站。这个地址指向的是另一台电脑,当它收到访问请求时,会返回网页数据给浏览器。至于这个过程的具体实现可以查阅这篇文章,反正最后浏览器拿到网页数据了。这个数据以 HTML 的格式返回,它描述了网页的结构。那么浏览器又是如何读懂 HTML 的呢?

浏览器引擎包含一类称为解析器的特殊模块,它将数据从一种格式转换为另一种可以存储在浏览器内存中的格式。举个例子,HTML 解析器拿到了以下 HTML 内容:

<section>
 <h1 class="main-title">Hello!</h1>
 <img src="http://example.com/image.png">
</section>

于是,解析器开始解析、理解 HTML,下面是解析器的独白:

嗯,这里有个章节。在这个章节里有个一级标题,这个标题包含的文本内容是 “Hello!”。另外在这个章节中,还有一张图片。这个图片的数据从这里获取:http://example.com/image.png

网页在浏览器内存中的结构被称为文档对象模型,简称 DOM。DOM 以元素树的形式来表示页面结构,而非长文本形式,包括:每个元素各自的属性以及元素间的嵌套关系。

A diagram showing the nesting of HTML elements

除了用于描述页面结构,HTML 同样包含指向样式文件和脚本文件的地址。浏览器发现这些后,就开始请求并加载数据。然后浏览器会根据数据的类型,指定相应的解析器来处理。脚本文件可以在 HTML 文件解析的同时,改变页面的结构和样式。而样式规则,CSS, 在浏览器引擎中发挥以下作用。

关于样式

CSS 是一门编程语言,开发者可以借助 CSS 描述页面元素的外观。CSS 全称 Cascading Style Sheets (译注:层叠样式表),之所以这样命名是因为多个 CSS 指令可以作用在同一个元素上,后定义的指令可以覆盖之前定义的指令,权重高的指令可以覆盖权重低的指令(这就是层叠的概念)。下面是一些 CSS 代码。

section {
  font-size: 15px;
  color: #333;
  border: 1px solid blue;
}
h1 {
  font-size: 2em;
}
.main-title {
  font-size: 3em; 
}
img {
  width: 100%;
}

大部分 CSS 代码被分割在称为规则的一个个分组中,每条规则包含两个部分。其中一个部分是选择器,选择器描述了 DOM 中需要应用样式的元素(上文说过,还记得吗?)。另一部分则是一系列样式声明,应用于与选择器匹配的元素。浏览器引擎中包含一个名为样式引擎的子系统,用于接收 CSS 代码,并将 CSS 规则应用到由 HTML 解析器生成的 DOM 中。

举个例子,在上述 CSS 中,我们有一条规则指定了选择器 “section”,这会匹配到 DOM 中所有 section 元素。接着,浏览器引擎会为 DOM 中的每一个元素附上样式注解。直到最后每个 DOM 元素都应用了样式,我们将该状态称为元素样式计算完毕。而当多个选择器作用在一个元素上时,源代码次序靠后的或者权重更高的 CSS 规则最终会应用到元素上。可以认为样式表是层叠的薄透写纸,上层覆盖下层,但同时也能让下层透过上层显示出来。

一旦浏览器引擎计算好了样式,接下来就要派上用场了!布局引擎接下来会接手 DOM 和已计算的样式,并且会考虑待绘制布局所在的窗口大小。然后布局引擎会分析该元素应用的所有样式,并通过各种算法将每个元素绘制在一个个内容盒子中。

页面布局绘制完毕后,是时候将页面蓝图转化成你所看见的实际页面了。这一步骤称为 painting(绘制),这也是先前所有步骤的最终整合。每个由布局定义的内容盒子都将被绘制,其内容来自 DOM,其样式源自 CSS。最终,从代码一步步重组而成的页面,展现在用户眼中。

以上就是以前的浏览器引擎所做的事情。

当用户滚动页面的时候,浏览器会进行重绘来显示原先在可见窗口外的页面内容。然而,显然用户都喜欢滚动页面!浏览器引擎清楚地意识到自己肯定会被要求展示初始窗口以外的内容(也称视口)。现代浏览器根据这个事实在页面初始化的时候绘制了比视口更多的页面内容。当用户滚动页面的时候,这部分用户想要看的内容早就已经绘制完毕了。这样的好处就是页面滚动变得更快更流畅。这种技术是网页合成的基础,合成是一种减少所需绘制量的技术术语。

另外,我们有时候也需要重绘部分页面内容。比如用户有可能正在观看一个每秒 60 帧的视频。也可能页面上有一个图片轮播或者滚动列表。浏览器能够检测出页面上哪一部分内容将要移动或者更新,并且会为这些更新的内容创建一个新的图层,而非重新渲染整个页面。一个页面可以由多个彼此重叠的图层构成。每个图层都可以改变定位方式、滚动位置、透明度或者在不触发重绘的前提下控制图层的上下位置!相当方便。

有时候一些脚本或者动画会修改元素的样式。这个时候,样式引擎就需要重新计算这个元素的样式(可能页面上许多其他元素也要重新计算),重新计算布局(产生一次回流),然后重绘整个页面。随着计算量的增加,这些操作会耗费很多时间,但只要发生的频率低,那么就不会对用户体验产生负面影响。

在现代 web 应用中,文档结构经常会被脚本改变。而哪怕只是一点小改动,都会或多或少地触发整个渲染流程:HTML 解析成 DOM、样式计算、回流、重绘。

Web 标准

不同浏览器解释 HTML、CSS 和 JavaScript 的方式也不一样。这就产生了各种影响:小到细微的视觉差异,大到用户无法在某些浏览器上正常浏览网站。近年来在现代互联网中,大多数网站在不同浏览器下似乎都表现的不错,而且也没有关注用户具体使用的是什么浏览器。那么,不同浏览器又是如何达到这种程度的一致性体验呢?

网站代码的格式,以及代码的解释规则、页面的渲染规则都是由一种由多方认可的文件定义的,即 Web 标准。来自浏览器厂商、Web 开发者、设计师等行业成员的代表组成的委员会制定了这些标准文档。他们一起确定了对于给定的代码片段,浏览器引擎应该显示的明确行为。Web 标准包括 HTML、CSS 和 JavaScript 标准以及图像、视频、音频等数据格式的标准。

为什么说 Web 标准是重要的?因为只要保证遵循了 Web 标准,就可以开发出一个全新的浏览器引擎,这个引擎可以处理互联网上数以亿计的网页,并绘制出和其它浏览器一样的结果。这也意味着在某些浏览器中才能运作的“秘密配方”不再是秘密了(译者注:例如,不再需要 CSS 私有前缀)。另外,正因为 Web 标准的存在,用户可以凭自己的喜好挑选浏览器。

摩尔定律的终结

过去,人们只有台式电脑。曾经有一个相对保守的假设:计算机只会变得更快更强大。这个想法是基于摩尔定律的推测:集成电路上可容纳的元器件的数目,约每隔 2 年便会增加一倍(因此半导体芯片的性能也将提升一倍、体积也将缩小一倍)。令人难以置信的是,这种趋势一直持续到了 21 世纪,并且有人认为这一定律仍然适用于当今最前沿的研究。那么为什么在过去十年中,计算机的平均运算速度似乎已经趋于稳定了?

顾客买电脑的时候不单单考虑运行速度,毕竟速度快的电脑很可能非常耗电、非常容易发热还非常贵!有时候人们想要一台续航时间良好的笔记本电脑。有时候呢,人们又想要一个微型的触屏电脑,带摄像头,又小到可以塞进口袋,并且电量足够用一天!计算能力的进步已经让这成为可能(真的很惊人!),不过代价就是运行速度下降。正如你在飙车的时候无法有效(或者说安全)地控制行车路线,你也无法让电脑超负荷计算的同时处理大量任务。现在的解决方案都是借助于单 CPU 多核。因此,现在智能手机普遍都有 4 个较小、较弱的计算核心。

不幸的是,过去的浏览器设计是基于摩尔定律(性能提升)会继续有效的假设。另外,编写能够充分利用多核 CPU 的代码也是极为复杂的。所以,我们该如何在这个到处都是小型计算机的时代,开发一款高速又高效的浏览器呢?

我们已经想到了!

在接下来的几个月中,我们将更进一步关注 Firefox 的变化,以及这些变化将如何更好地利用现代硬件来实现一个更快更稳定的浏览器,从而让网站更加多姿多彩。

皮皮虾,我们走!

Growth CSS

Growth CSS

@(Front End Growth)[前端开发, Vue.js, JavaScript, github]


Front End Growth 系列文章。记录 XX 前端成长过程的点滴。仅供参考,也许不具备通用性,请结合自身实际,切勿强行模仿~
Growth CSS 介绍了 XX 对 CSS 的认知以及学习、应用上的建议。


What is CSS

是一门面向交互设计、视觉设计的声明式语言

  • 视觉
    • 布局 (display、margin、padding、width)
    • 字体排印 (font、text、color)
    • 装饰 (background、box-shadow、gradiant)
    • 动画 (animation、transistion、transform)
  • 交互
    • 反馈 (:hover, :visited)
    • 引导 (position: fixed)
    • 互动 (:hover .show)

也是一门需要一些技巧或工具来优雅编码的伪 OO 语言

  • 面向对象
    • 继承 .parent{styleA: xxx;} .child { styleA: inherit; } / .parent() {} .child { .parent(); }
    • 扩展 .classA.classB / .classA() {} .classB() {} .classC() {} .classFinal {.classA(); .classC(); style:xxx;}
    • 重载 .classA.classB .classA { xx: oo} .classB { xx: xx}
  • 代码规范
  • 代码复用 DRY (Less)
  • BEM
  • 变量、函数命名
  • 权重控制
  • 语义性

How I learn CSS

  • 概念(flexbox 布局)
  • demo(动手调试一下所有 flex 属性)
  • 应用(使用所学技术,实现一个页面 or 模块 or 方案)
  • 融汇(与已有知识体系进行关联,梳理知识、归纳、分类)
  • 贯通(结合已有的相关联知识点,头脑风暴,例如:实现垂直居中的 N 种不同方案 )
  • 初心(根本目的是为了实现视觉效果,所以心中永远有一个当前场景最合适方案)

How I Code CSS

Consideration

  • 视觉还原度
  • 兼容性
  • 性能
  • 开发效率
  • 可维护性
    • 语义性
    • 权重控制
    • 嵌套层级
  • 可控颗粒度
  • 调试技巧

CSS Code Standards

BEM

Less

Learning Tips

毕竟 CSS 是一门“面向视觉”的语言,所以学习资料尽量以图像为主,可以加深记忆效果。

@Design

与设计师的沟通

设计理念

一致性 可用性 易用性 反馈

这里不一定实时更新,可以关注 github 地址获取最新内容:

https://github.com/xunge0613/front-end-growth/blob/master/tech-growth/growth-css.md

前端开发负责人修炼指北

前端开发负责人修炼指北

大家好,我叫XX,江湖人称吃土小2叉,目前担任公司的前端负责人半年多了,一路上摸爬滚打,历经团队人员变动,近日颇有感触,于是结合自己近半年的前端负责人实践经验,权当作一个学习记录,整理归纳一下前端负责人的修炼要点(大部分只是记录了关键词,没有详细展开),以及自己的实践记录。一些观点可能不是很成熟,也可能都是一些政治正确的废话…… 欢迎各位老司机多开车指点指点,交流交流哈~.

职责

  • 营造存在感、归属感、成就感
  • 把控技术方向
  • 新人引导
  • 促进团队提升、培养团队
  • 权衡公司利益以及 队员利益
  • 与其他部门衔接和沟通
  • 创造希望 (eg: 画大饼、某种意义上的程序员精神鼓励师)

关键词

团队建设、技术选型、人员安排

  • 团队建设
    • 技术氛围
    • 人文氛围
  • 技术选型
    • 产品需求
    • 稳定性
    • 兼容性
    • 开发效率
    • 招人难易度
    • 留人难易度
    • 转型成本(时间成本、学习成本)
    • 舍弃用户成本(转化率:兼容性; 访问量:SEO)
  • 人员安排
    • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
    • 让普通的人加速提升 (技术栈:最成熟的技术)
    • 淘汰余下的人

常见问题分析

面试时经常遇到一些人的离职原因就是以下一些……

1. 没有提升

什么是提升?

  • 更快解决问题 7
  • 更优解决问题 8
  • 解决以前不能解决的问题 9
  • 编程能力提升 (编码、设计、架构) 9
  • 掌握新技术、新语言、新工具 5
  • 工资提升 6
  • 知名度 7

注: 数值为XX认为的较为合理的权重值,满分10,个人意见,仅供参考

如何提升?

缺一不可

  1. 时间
  2. 方向
  3. 坚持
  4. 实践

加分项

  • 聪明 (XX注:可遇不可求)
  • 有老司机指点 (XX注:可遇不可求)
  • 好奇心
  • 自我驱动力/主观能动性
  • 专注

注: 除去 聪明、 有老司机指点, 这两个是可遇不可求的; 其余都是可以后天培养的。

为什么没有提升?

工作只使用旧框架、旧技术 【应聘人经常提及】
基础薄弱,学新技术难,求带,抱大腿
光看不练
没有时间
前端要学的太多太杂,学了这个忘了那个
新框架一个又一个, 来不及学

负责人能做的

  • 保证产品稳定性,满足产品兼容性需求的情况下,尽量让团队使用最前沿的技术
  • 推动团队技术学习、分享氛围,必要时给予物质奖励
  • 为成员腾出一定自由时间
  • 让自己成为队员的大腿、答疑解惑
  • 完善技术文档
  • 写优秀的代码
  • 造轮子、改进项目基础设施
  • 挡需求、砍需求、改需求、加需求

负责人不能做的/很难做的/不应该做的

  • 不应该回答what的问题、 减少回答how的问题,而是更多回答why的问题
  • 不应该每天催着队员去学习、去分享,而是要激发队员的自我驱动力、主观能动性
  • 不应该安排超负荷任务,而是分配合理的任务总量
  • 不应该花费大量时间(80%)开发业务需求,而应该花一半时间(50%)思考和设计如何改进现有开发模式

2. 没有成就感

如何获得

  • 回报 >= 付出 (精神、物质)
  • 对产品的认可
  • 对技术栈的认可
  • 对自己付出的认可
  • 对他人付出的认可
  • 助人且助人的反馈是积极的
  • 个人发展、晋升

概况: 回报 >= 付出 (精神、物质)

3. 加班太多 没有时间 到家后太累了

首先明确一点,业务需求是永远做不完的

我们能做的,只是每周根据已有的开发资源,开发相对最重要最紧急的业务

另一方面,也要注意: 程序员自我提升 的重要度也是极高的

队员层面

  • 合理评估工期
  • 不断提升自己,不断提高效率
  • 量力而为,保重身体

负责人层面 【主要背锅人】

  • 合理审核工期
  • 合理安排任务 【重要】
  • 技术选型是否合理、是否高效
  • 新人的引导是否到位

4. 技术分享参与度不高

如何改善

  • 负责人牵头分享
  • 奖励机制
  • 避免布置过饱和任务量

应聘人的期望

(以下回答来自XX面试过的应聘人)

  • 我比较期待能有一个经常相互讨论最新技术的环境
  • 技术氛围好点,可以互相交流的,然后加班不要太多,有意义的加班可以接受
  • 希望有挑战性和持续成长空间,同事之间比较容易沟通的,当然做的产品有趣就更好了
  • 希望有大牛带
  • ……

XX实践

团队建设

技术氛围

  1. 技术分享考评制度(鼓励竞争 、 与培训机会、年终考核挂钩)
  2. 定期 code review (2周1次) 优先级: 高
  3. 不定期 小分享 (不限次~2周1次) 优先级: 高
  4. 定期 大分享 (2个月1次)
  5. 鼓励参与翻译英文技术文章
  6. 整理、维护、更新前端知识库 wiki (涵盖: 代码规范、工具教程、开发流程、组件 Demo、语言教程等)
  7. 前端每周一题 , 以经典案例题形式传授实际价值较高的知识点
  8. LeetCode 刷题活动 (算法题为主)
  9. 每周周会只探讨各自遇到的难题1~2个,思考更优解
  10. 开源项目 【构思中】
  11. 新技术交流、研讨会 【构思中】
  12. 以上各种分享,负责人带头进行

考核制度 DKP

v0.1 版本 考察两个维度: 分享贡献度、业绩贡献度; 每个月设置合格线,低于合格线进入考察期

  • 试行了1个月,实际效果一般,参与度不高,仅一人达成分享贡献度合格;
  • 不同产品线业绩难以量化衡量;
  • 较反感惩罚制度

v0.2 版本 仅考察 分享贡献度。不设合格线,分值仅作为奖励评定标准

团队氛围

(需加强)

  • 多关心队员真实诉求,阶段性一对一对话
  • 设定阶段性目标(例如:官网重构计划),达成后一同庆祝
  • 定期组织 TeamBuilding

技术选型

数据驱动 + 业务驱动 + 人才驱动

  • 产品需求
  • 稳定性
  • 兼容性
  • 性能
  • 开发效率
  • 技术价值 (对程序员自我提升产生的价值)
  • 招人难易度
  • 留人难易度
  • 转型成本(时间成本、学习成本)
  • 舍弃用户成本 (数据驱动)
    • 舍弃兼容性带来转化率下降的成本: IE8 用户
    • 舍弃SEO造成访问量下降的成本: SEO 流量

人员安排

  • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
  • 让普通的人加速提升 (技术栈:最成熟的技术)
  • 淘汰余下的人

技术选型规划

以 PC 官网前端重构计划为例

现状

jQuery + 类 require.js 加载机制 + less + gulp + C# , 传统电商网站

目标浏览器

不低于 5% 访问量的浏览器

目标流量来源

SEM + SEO + 市场活动推广

其中, SEO 目前平均占比约 15% 流量

业务痛点

设计风格不统一、特别大量重复性工作 (各种合作方系统定制化移植官网)、 前后端耦合程度大

人员痛点

技术栈落后、招人难、留人难

重构好处
  • 组件化设计: 提高代码复用性;有助于快速移植组件、促进合作方项目进度同步
  • 技术栈升级: 有利于招人以及留人
  • 前后端分离: 有利于提升开发效率
重构弊端
  • 时间成本: 大量
  • 兼容性成本: 只兼容IE9+
  • 白屏时间: 比起传统服务器端渲染,会存在一定的白屏时间,而短期内不一定会使用 node.js + vue.js SSR
路线图
  1. 在后台管理系统中试点 Vue.js 框架,积累 Vue.js 经验 【DONE】
  2. 在完成 2~3 个后台管理产品后,渐进式(帮助中心页入手)改造官网前端 【View层 Vue.js框架 ; Action 层 c# .net】 【PLAN】
  3. 在确定舍弃 IE8 用户后,官网全站转型 Vue.js 框架
  4. 在确定舍弃 SEO 流量 改用 Vue-Router , .net 只提供容器
  5. Vue.js + Node.js 服务器端渲染有一定积累后,官网前后端完全分离

近期实践

时间 分类 内容
2017.4.8 讲座 前端小组集体参加中第二届国前端开发者大会…… 公司报销
2017.4.14 大分享 XX: 自动埋点工具介绍(很low……) ATM https://github.com/xunge0613/ATM
2017.4.21 小分享 XX: 掘金翻译计划参与体会 + GitHub Review 功能
2017.4.23 技术研讨 官网 PC 前端重构规划

任务安排

2 – 8 原则

如何做

数值仅供参考,具体情况具体分析
每周任务安排 4 天工作量
每天花 0.2 天 , 约 1.5 ~ 2 小时,自我提升

目的

为了提升队员开发效率

定期安排技术型任务

  • 督促技术提升
  • 考核方式

按需分配需求

一般业务需求无非考验以下两点

  • 业务熟悉度
  • 技术熟练度

理想情况下,对于业务不熟悉的队员,优先分配需要熟悉业务的需求;反之亦然

结语

知易行难
贵在坚持


题外话: XX的前端奇妙历险

3年弯路
13 年 4 月实习加入一家初创公司,工作不到半年,原先前端 leader 转岗做运营,只剩下我一个前端,持续了半年左右。由于人少,写前端的同时还要写 C# 代码,偶尔研究 SEO,兼职半个网管,还负责了每天晚上给加班童鞋点晚餐外卖…… 这个状态差不多从进入公司开始持续了 2 年。所以虽然自己工作了也有将近 4 年了,但精力比较分散,走了很多弯路,做了许多重复性劳动;同时又与外界其他前端的交流很少,唯一和外界的交流机会几乎就是当面试官与应聘人交流;且当时很长一段时间疲于业务开发,经常 9、12+、6 ,自己学习主动性下降了许多,业余一有休息时间自己几乎也是“荒废”了,也不再如大学时自学前端那阵子折腾自己的博客站点、折腾各种技术、写博文做小结(单反穷三代、游戏毁一生)。前端技术的沉淀比较欠缺。另一方面,也大约3年左右时间单相思,受困于情感问题耽误了不少时间。

简单来说,前 3 年走了很多弯路,几乎是 3 年的工作时间以及 1 年的加班时间,换来了 0.5 年的前端经验,原因是: 精力分散、视野狭窄、缺乏实践、缺乏学习主动性、缺少反省、公司缺人。

决定性时刻
后来,陆陆续续前端团队一点点扩张,但直到去年年中,一共也只有 3 个前端,应付公司 3 个电商类前端产品(PC + M)。也一直没有所谓的前端 leader,都只是各自负责各自的产品线,大家也都很年轻,2~3年经验。当时 CTO 问我,要不要招一个资深的前端来带我们,还是让我们自由竞争,我当时也挺迷茫和纠结,一直以来,都感觉自己对于前端职责的定位以及今后发展方面,缺乏系统和全面的认知,以及也不清楚技术团队的 leader 的职责应该是什么,觉得如果招个老司机,自己能有更明确的目标和规划,同时对公司来说虽然要负担更多的薪资开销,但是想必能有更多可能性,会有更多回报。而自己这几年在前端上基本是靠自己摸索以及参考知乎上的解答。

半年来
结果是,去年下半年,我受命担任前端组负责人…… 恰逢自己终于决定放弃 3 年多的单相思。于是打鸡血般花了大量时间接触外界,开阔技术视野,(包括参加了许多前端的知乎 live ,从最早围观的小爝老师、Hax 老师…到近期 vczero 、吕毅以及 justjavac 大神们的 live,以及 姬光、i5ting、小问等大大的 gitchat……以及 vczero 和 前端早读课情封 的小密圈…… 以及加了 豪情大大的前端 js 跳板 QQ 群…… 以及传说中的微信小程序联盟论坛,以及相关的 QQ 群,每天至少回答群里一个小程序的技术问题 ),研究新技术,补习自身基础,研究如何带团队,促进团队提升… (然后也就有了现在这篇文章) 现在前端团队一共 6 人…… 还在招…… 欢迎推荐……

Anyway, 最好的学习时间是昨天和现在,即使花了 3 年多走了那么多弯路,至少,现在正了一些,也不错啊。

最后,还是想感谢一下,领导对我的信任 =。= 以及同事们的支持以及各位大神们的指导~

 

前端开发经验札记

最后更新:2014年5月1日1:57:33

作者: 徐迅 (清风迅来 XX)

真正从事Web前端开发有一年多了,而接触前端最早可以追溯至小学时候电脑课上的网页制作,那个时候还在使用Front Page(我才不会说那个时候自己设计的网页巨丑…);后来一直到大学才“重拾旧业”:大二曾帮老师做过课程介绍网站,使用的仍然是DreamWeaver,并开始搭建 xuxun.me ;大三拥抱notepad++和zen-coding,开始折腾JavaEE的项目;大四毕业设计又回归PHP,偶尔接触了Python;工作以后爱上sublime text 2、less和coffee script,在C#坑中渐行渐远。

希望这篇文章能一直更新下去吧.

加油XX,奔跑在大前端之路上吧!

一、前端语言基础

(一)HTML

     1 标签语义化:使用合适标签,少使用无语义标签
     2 使用 <!DOCTYPE html> 既可以向前兼容,又体现了你网站的高大上!
     3

(二)CSS

     1 选择一款合适的CSS预处理语言(个人比较喜欢Less),大大提升CSS编写效率
     2 通用的样式提取成 .class 或者 less 中的 mixin() {} 更佳
     3 多使用限定度高的选择器, 例如 > + , 尽量避免后代选择器过度使用
     4 多用组合少用继承,减少耦合
     5 选择器权重222原则(XX自创……): 选择器权重不超过222,即最多2个id,2个class和2个tag……
     6 CSS伪类是个神器,例如使用:hover、:after等伪类可以替代JS实现不少效果

(三)JavaScript

     1 JS我是渣.

二、前端框架基础

(一) Bootstrap

     1 Bootstrap 的less 代码质量好,价值高,推荐学习

(二)JQuery Mobile

     1 深坑,慎入

三、前端杂七杂八

     1 适当了解浏览器的渲染机制,避免代码性能过低
     2 替换 .class 优于 替换 <xx style=”xx:xx;” ></xx>
     3 图片记得压缩, jpegtran 是个不错的jpg图片无损压缩工具

四、前端各种坑爹

1 IE 7 不支持 console.log ,因为 IE7 根本没有 console ,所以当你使用 IE 7 运行有 console.log 的页面你会悲剧..
2

 

徐迅 / 清风迅来

XX   / Dalston Xu

Google

解决Swiper中translate3d导致字体模糊

2014年4月11日0:34:17

今天公司的设计师sama跟我说,官网旧机回收首页上有个UI问题,说是用户晒单那部分的字体模糊,如下图所示:

translate3d导致字体模糊
translate3d导致字体模糊

(PS:以上原先是#666的字体颜色,为了使效果更明显于是我改成#000,原先在浏览器上比这个更模糊的画面木有截取下来= =)

嗯,这是使用了 swiper 插件,导致了文字出现了模糊。(不过在firefox、IE中倒是好的!)

于是乎我就开始找问题原因之所在咯,第一个想到是不是字号大小不一致,结果我查看了下一切都正常都是12px,特地调大还是会有模糊。

接着我想到的就是去swiper的官网上看看它的API上有木有相关的方法。

结果还真有一个:手册上有一个参数名是: useCSS3Transforms ,默认为true的,改成 false即可。

但是如果真的这么快就可以解决这个问题的话,我就用不着大费周折写这篇文章了吧……

所以结果是虽然修复了字体模糊问题,但是带来了另一个大问题.. chrome下每次滚动竟然4个一起滚了(原先每次移动1个项的)… orz ..!

于是没办法,只好在保持使用 css3 transform 的 translate3d 的情况下,继续寻找解决方案了。

在stackoverflow上,我也找到相关技术的话题讨论: http://stackoverflow.com/questions/8024061/webkit-blurry-text-with-css-scale-translate3d

网上有说是使用:     -webkit-font-smoothing: subpixel-antialiased; 这个的

也有说使用  -webkit-perspective: 1000; 这个的…

当然结果也都是木有用……

我甚至在 github 上面swiper官方的issue中找到了相关问题: https://github.com/nolimits4web/Swiper/issues/45 但问题是作者似乎木有给出有效解决方案=-=

倒是解释了下为何使用 translate3d,说是这样可以强制浏览器使用GPU来渲染,可以大大提高页面的性能,尤其是移动端(但会在一定程度上降低质量…正如API文档中所写的)

好吧,最终,又是经由API文档中另外一个参数的启发:

 roundLengths
Set to true and Swiper will round width/height values, may be useful if you have rounding errors (like 833.48px width) in responsive swiper.

于是就想是不是因为外围容器它的 translate3d 属性有小数的原因。

然后我就去看了下,结果还真是如此! 哦也!

我发现当 translate3d 属性中只要出现小数,那么容器中的文字就会有一定程度的模糊,当该属性为 *.5 时,模糊的现象最严重。

translate3d的值出现小数时会导致文字模糊
translate3d的值出现小数时会导致文字模糊

当这个值为整数的时候就木有模糊现象了!

于是就决定更新容器宽度,使之能被4整除!

这样就解决该问题了…

translate3d的值改为整数以后文字就不模糊了
translate3d的值改为整数以后文字就不模糊了

SO,现在看起来舒服多了吧~

另外: IE11 下,在 dulplicate的slide中,用户的微博头像会错位… 这个问题有点坑。。倒是IE10等都是好的..

XuXun 清风迅来

2014年4月11日0:09:01

学习使用CoffeeScript(一)以及部分js基础知识扫盲……

2014年3月26日22:39:49

前一阵子一直听马老板推荐coffee script 这个神器。
我的理解是这货是一个用于JS预处理的东东,coffee 之于 javacript 就如 less 之于 css。
今天难得下班比较早,外加早上又不小心点到她人人主页围观了一会儿以及下午又被来面试前端的童鞋的高水平给刺激到了..
于是就稍微研究了一下这个东西,顺便开启博客恢复更新模式..
好了,废话不多说了,先上coffeescript 的官方网站: http://coffeescript.org/
然后打开nodejs客户端,输入以下命令:
npm install -g coffee-script

1-install-coffeescript

下载安装完之后就可以使用啦,文档的话还是参照官方网站好了。
2-test-coffeescript
2-test-coffeescript
接下来安装官网上的介绍做一下示例程序~
3-demo-coffeescript
3-demo-coffeescript
先是简单的一个定义语句

4-use-coffeescript

由 coffee 转为 javascript 之后,多了不少东东呢..
5-coffeescript-to-javascript
5-coffeescript-to-javascript
嗯.. js孤陋寡闻的我还是研究下这个“简单”的代码吧。。
首先,这个似乎是由一个匿名函数包裹起来.. 最后为啥尼玛又call调用自己啊我戳。。
查阅了一下 MDN的手册 ,
上面的解释是:
 The call() method calls a function with a given this value and arguments provided individually.
说人话大概就是:call()方法根据给定的this值和若干参数来调用一个函数…
实际操作呢结合到上面的代码,就是:直接调用这个匿名函数的call方法,木有参数。
查阅了JS高级程序设计这本书的第116以及117页,5.5.5 函数属性和方法。
上面写到:
每个函数都包含两个非继承而来的方法:apply()和call()。两者的用途都是在特定的作用域中调用函数,实际上等于设置函数体内的this对象的值。
而函数体内的this对象,由5.5.4 函数内部属性 可知,
函数内部有两个特殊对象,arguments 和 this, 其中 this 的行为与 Java和C#中的this大致类似。
换句话说,this引用的是函数据以执行的环境对象——或者也可以说是this值(挡在网页的全局作用域中调用函数时,this对象引用的就是window)。
举个栗子:
window.color = “red”;
var o = {color:”blue”};
function sayColor() {
     alert(this.color);
}
sayColor();       // ???
o.sayColor = sayColor ;
o.sayColor();   //  ???
—————————
一定要牢记:函数的名字仅仅是一个包含指针的变量而已。因此,即使是在不同的环境中执行,全局的sayColor()函数与o.sayColor() 指向的仍然是同一个函数!
—————————
以上
清风迅来(XuXun)
Dalston Xu

弱弱发一则招聘启事我知道肯定木有人来看的~~~

 爱回收网招前端开发实习生,www.aihuishou.com
在这里,你将与视觉设计师一起,参与完成产品线Web功能的开发;
我们希望你,关注新事物、新技术,有较强的学习能力,喜欢挑战,热爱前端开发;我们希望你,可以熟练使用各种 Web 前端技术,包括CSS布局、解决常见浏览器兼容性问题;
我们希望你,有基于Ajax 应用的开发经验,了解一门后台开发语言。
有兴趣的可以留言~