前言 这次的 why what or how 主题：JavaScript 对象 & 原型。 此类文章在百度上一搜一大把，其实不用再写了，但是本着把这个问题解释的清清楚楚明明白白，还是开始写了。 原因如下： 1. 面试宝典类文章，弄张图片一糊弄，让人觉得自己理解了。 2. 解释类文章，告诉你一堆语法，对语法一顿解释，告诉你就是这样的，还是没说清楚。 3. 很少有文章单独解释这个点！但这个点是基础！真的很重要！ 所以本篇文章想说一说对象 & 原型，但为了确保能顺利理解，请先看完 JS 变量存储？栈 & 堆？NONONO!，因为该篇文章从变量存储的角度来解释 JavaScript 对象 & 原型，请确保看完，在看这篇文章。 什么是对象？ 既然要说清楚，
前言 javascript 是以单线程的形式运行在宿主环境下，javascript 采用了回调的形式来解决异步任务。 为什么是单线程？ javascript 的最开始的出现是为了给 web 页面增添一些动态的效果，那么就避免不了获取页面上的元素信息，如果 javascript 是以多线程的形式运行在浏览器内，如果两个线程内的 javascript 同时去获取/修改，某个页面上的元素，那么浏览器该让哪个 javascript 线程拥有获取/修改该元素的权限呢？由于元素的信息会经常性的发生变化，那么又改如何去同步各个线程内所保存的元素信息呢？ 所以综合以上问题， javascript 是单线程的原因就显示意见了，单线程在执行时，对于元素信息的引用在同一时间仅可能只有一个，那么以上所有的问题都不存在了。 什么是异步任务？ 任何代码在执行时，都会碰到一些需要经过大量时间运算或是等待的代码，在浏览器的环境下，常见的就是 http 任务，比如：资源的加载（图片的 onload 事件），ajax 的请求（XMLHttpRequest 的 onLoad 事件）还有页面元素的点击事件以及
前言 通过 浏览器下的 Event Loop ，可以得知 javascript 是一门事件驱动的语言， javascript 主线程通过不断的调用事件队列中的事件来完成异步任务。那么 Node 下是否也是如此？ Node 下的事件队列 在 Node 官网有这样一篇文章：The Node.js Event Loop, Timers, and process.nextTick() 。 该文章主要讲述了 Node 中是如何处理以及实现 Node 下的 Event Loop。 主要包含以下内容： 事件队列 不同于浏览器，Node 下的有 6 个事件处理阶段，其执行顺序和队列名称如下： ┌───────────────────────────┐ ┌─>│ timers │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ pending callbacks │ │ └─────────────┬─────────────┘ │
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 这次的 why what or how 主题：现在几乎所有人都知道了 HTML5 ，那么 H5 到底相比于 HTML4 有什么区别呢？ 升级版？标准版！ HTML5 做为 HTML 标准的第 5 版，于 2014 年发布，相信关注过 HTML5 的发展史的朋友都知道该版本是 WHATWG 和 W3C 握手言和后诞生的，是 W3C 组织与浏览器厂商相互妥协的结果，其中的绝大部分规范都由 WHATWG 组织所制定，之后由 W3C 采纳并入标准中。
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章解释清楚一个问题。 作为 why what or how 的第一章，选一个较为简单的话题，什么是 HTML ？ 释义 HTML - HyperText Markup Language，超文本标记语言 标记语言，一类以固定的形式描述文档结构或是数据处理细节的语言，一般为纯文本形式，其内容作为其他程序的输入。 因此，HTML 是一种用于描述网页的标记语言，纯文本，其内容作为浏览器的输入。浏览器会解析 HTML 文本内容，最终呈现页面。 那么超文本又是什么？ 在网页出现前，人们的阅读习惯是从前往后，从上到下，就像阅读小说，必须从头到尾的看完，思维是单向的，并不存在岔路口。而超文本从字面上理解就是：超出了一般的阅读习惯，看文章的时候思维是发散的，
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 why what or how 的第二章，什么是 CSS ？ 释义 CSS - Cascading Style Sheets，层叠样式表 CSS 也算是一种标记语言，其内容作为浏览器的输入，浏览器会解析其文本内容，作为 HTML 附加的样式信息，用以修饰标签。 标记语言，一类以固定的形式描述文档结构或是数据处理细节的语言，一般为纯文本形式，其内容作为其他程序的输入。 样式表大家都很清楚，记录样式信息的表格，以键值对的形式存在，格式如下 p { font-size: 10px; } 那么何为层叠呢？层叠的意义是什么？ 层叠，字面意思：层层叠加，我们知道 HTML
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 这次的 why what or how 主题：什么是 JavaScript ？ 释义 JavaScript：一种解释性脚本语言。 解释性脚本语言：一类不具备开发操作系统的能力，而是只用来编写控制其他大型应用程序的“脚本”，但其内容的的执行不需要提前编译的语言。通常作为别的程序的输入。 JavaScript，是一种用于描述网页逻辑，处理网页业务的解释性脚本语言，纯文本，其内容作为浏览器的输入，浏览器负责解释编译运行其内容。 目前 JavaScript 也成功被应用于服务端，服务端的 JavaScript 用于描述业务逻辑，其内容作为 node 的输入， node 负责解释编译运行其内容。 JavaScript 是伴随着浏览器出现的一门特殊的语言，特殊在哪呢？ JavaScript 是唯一一门所有浏览器都支持的脚本语言，也就说如果你的
前言 这次的 why what or how 主题：单页应用的 router 模式，Hash、History是什么？ router 作为单页应用中重要的组成，有两种模式供我们选择，那么这两种模式的区别如何，分别的优势又在哪里？ 想要深入对比两种模式的区别，我们首先要知道什么是路由？ 什么是路由？ 路由定义如下：路由为 URL 的路径，也就是 URL 中的 path 部分，一个路由对应一个具体的资源，可能是文件，可能是数据。 在单页应用出现之前，路由已在服务端被广泛使用，那么前端何时开始有了路由？ 伴随着浏览器性能的提升、网速加快、Ajax 技术的成熟，部分前端程序员发现，使用 JavaScript 在前端维护一个模板，然后在用 Ajax 去服务端获取数据，就能够将模板和数据拼凑成一个动态的页面呈现给用户。随着这项技术的日渐成熟，一个问题渐渐的显示出来：如果
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 这次的 why what or how 主题：如何使用背景，或者说如何将背景使用到极致？ 背景，作为 css 中的老牌属性，相信大家并不陌生，相关属性有的也不少，希望大家在看这篇文章时，先放下对背景的固有印象，跟着下面的思路来深入的了解下浏览器是如何使用这些属性的。 既然想要深入了解，cosplay 成浏览器体验一把背景绘制是再好不过的了。 那么我们正式成为浏览器，拿起画笔，画出代码所规定的背景。 绘制 假设浏览器也就是我们，需要解析以下这段 css 并为元素绘制背景。 .box1 { background-color: #000; background-image: url(image.png); background-size: 40px 40px; background-origin: border-box;
前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 这次的 why what or how 主题：如何使用 Flex ？ 是什么？ Flex - 一种布局方式 在深入了解前，先来看看浏览器的支持情况吧： 一片绿色，那还等什么呢？赶紧掌握呀~ 先了解了解布局的发展史，在了解历史的基础上在回头来看看 Flex ，以史为镜，可以知兴替嘛~ 布局发展史 * Table 作为 HTML 的老牌元素，Table 虽然作为表格存在，但是很长一段时间却被用来布局，大致的过程就是将设计稿按照表格切好，然后在表格响应位置放上内容。虽然笔者没有经历过这个阶段，但想想也是很复杂的。之前在学校的时候，学校的官网就是用表格来写的页面，不知道现在改了没有。 * div + css 可以说这是目前大多数网站的布局方式，
前言 这次的 why what or how 主题：JavaScript 类型转换。 什么是类型装换，以及为什么要进行类型转换？相信绝大多数熟悉面向对象的开发者们都知道是为了匹配类型！ 但，这是 JavaScript 的世界，可以说原本就是没有类型系统的，那么为什么 JavaScript 的世界也有类型转换？ 为了容错！并且 JavaScript 世界的类型转换也不是发生在对象上，而是在基础类型！ 类型！ 这不是刚说完 JavaScript 没有类型，怎么开始说类型了？ 这里指的是基础类型，相信大家对于 JavaScript 数据类型已经充分了解了，这里也不啰嗦主要有以下 7 种。 * 数值： 1、1.0、1e10 * 字符串："string"、"foo"、"
前言 这次的 why what or how 主题：JavaScript 变量存储。 无论那门语言，变量是组成一切的基础，一个数字是一个变量，一个对象也是一个变量，在 JavaScript 中甚至连一个函数都是一个变量。 那么如此重要的变量，在 JavaScript 中究竟是如何进行存储的？ 栈 & 堆 ? 栈（Stack）又名堆栈，它是一种运算受限的线性表。限定仅在表尾进行插入和删除操作的线性表。 在百度上搜索 JavaScript 变量存储，能看到很多文章，无外乎一个结论： 对于原始类型，数据本身是存在栈内，对于对象类型，在栈中存的只是一个堆内地址的引用。 但是，我突然想到一个问题：如果说原始类型存在在栈中，那么 JavaScript 中的闭包是如何实现的？ 当然想要深究这个问题，有必要先把栈（Stack）和堆（Heap）给说说清楚。 那好，
console.info 本文翻译自 Google 的官方文档，该系列共 4 篇文章，从内部观察现代浏览器 (Chrome)，同时解答了浏览器的内部架构，讲述了浏览器从输入 url 到页面呈现的全过程。 原文链接: inside-browser-part4 前言 这是 从内部观察现代浏览器 (Chrome) 系列文章的第四篇。在上一篇文章中，我们知道了浏览器是如何将代码转化成网页的。在这篇文章中，我们将会知道，事件合成器是如何顺畅的处理用户的交互。 从浏览器的角度看待用户的输入 何为输入？使用鼠标在文本框中输入或是使用鼠标进行点击？是的，这些都是，但是从浏览器的角度看这个问题，输入意味着用户与网页交互的所有行为。比如：鼠标滚动、鼠标移动、滚轮滚动、触摸事件等等。 那么如何处理输入？当用户触发了 touch 事件时，浏览器进程是第一个知道 touch 事件发生的，但它却仅仅知道 touch 事件发生的坐标，因为选项卡中的内容完全是由渲染进程所控制，浏览器进程并不知道。
translate
console.info 本文翻译自 Google 的官方文档，该系列共 4 篇文章，从内部观察现代浏览器 (Chrome)，同时解答了浏览器的内部架构，讲述了浏览器从输入 url 到页面呈现的全过程。 原文链接: inside-browser-part3 前言 这是 从内部观察现代浏览器 (Chrome) 系列文章的第三篇，在先前文章中，我们了解了浏览器的多进程架构以及一次导航到底发生了什么。在这篇文章中，我们将会了解到渲染进程到底做了什么。 渲染进程直接与 Web 页面的性能挂钩。由于渲染进程涉及到很多内容，处理了很多逻辑，并不是一篇文章能够完整描述的，这篇文章仅是一个概述。如果你想更深入的了解，可以查看the Performance section of Web Fundamentals这篇文章。 主要构成 所有选项卡内部的逻辑，都由渲染进程处理。在渲染进程中，主线程处理了绝大部分的网页代码。由 Worker 或 Service Worker 注册的
translate
console.info 本文翻译自 Google 的官方文档，该系列共 4 篇文章，从内部观察现代浏览器 (Chrome)，同时解答了浏览器的内部架构，讲述了浏览器从输入 url 到页面呈现的全过程。 原文链接: inside-browser-part2 前言 这是 从内部观察现代浏览器 (Chrome) 系列文章的第二篇，在上一篇文章中，我们了解了浏览器的组成，以及如何将任务分配到不同的进程 & 线程。在这篇文章中，我们将深入了解：为了将一个 web 页面呈现到浏览器上，各各不同的进程 & 线程是如何进行协作的。 浏览器都会有这个简单的场景：用户在导航栏里输入 url ，接着浏览器到对应的服务器获取数据并将页面内容呈现到浏览器上。在这篇文章中，我们将了解用户请求一个站点，浏览器准备去渲染页面这个过程，也就是导航。 导航始于 Browser 进程 我们在第一篇文章( CPU、GPU、内存以及多进程架构 )中提到过，
translate
console.info 本文翻译自 Google 的官方文档，该系列共 4 篇文章，从内部观察现代浏览器 (Chrome)，同时解答了浏览器的内部架构，讲述了浏览器从输入 url 到页面呈现的全过程。 原文链接: inside-browser-part1 前言 该篇文章作为本系列的第一篇，我们先来了解下关于计算机的核心术语和 Chrome 的多进程架构模型。 计算机的核心 - CPU & GPU 在了解浏览器是如何运行之前，我们必须对它所处的运行环境有所了解，毕竟浏览器是基于这些硬件的。 CPU 中央处理器 CPU (Central Processing Unit) 是计算机的大脑，一个 CPU 核心就像是一个员工，能逐个处理分配的任务。它可以接收数学、艺术在内的所有任务，并将任务的处理结果返回给任务的发布者。 曾经大多数的 CPU 是单核的，而目前，我们经常使用多核的 CPU ，多核
translate
console.info 本文翻译自 sessionstack.com，该系列共 19 篇文章，解释了 JavaScript 是如何在浏览器中工作，深入到了 JavaScript 解释器的工作原理，以及 JavaScript 技术实现细节。 原文链接: How JavaScript works: inside the V8 engine + 5 tips on how to write optimized code 前言 几周前，我们开始了系列：深入研究 JavaScript 及其工作原理。我们认为：通过了解 JavaScript 的组成以及这些组成如何一起发挥作用，就将能够编写更好的代码和应用。 该系列的第一篇文章着重介绍了 JavaScript 的引擎、运行时和调用堆栈。这篇文章将深入探讨 Google
translate
console.info 本文翻译自 sessionstack.com，该系列共 19 篇文章，解释了 JavaScript 是如何在浏览器中工作，深入到了 JavaScript 解释器的工作原理，以及 JavaScript 技术实现细节。 原文链接: How JavaScript works: an overview of the engine, the runtime, and the call stack 前言 伴随着 JavaScript 越来越流行，越来越多的领域都能看到它的身影比如：前端、后端、APP 混合应用程序、嵌入式设备等。 该篇文章是本系列文章的第一篇，旨在深入探讨 JavaScript 及其工作方式。我们认为：通过了解 JavaScript 的组成以及这些组成如何一起工作，
browser
前言 JS 的本质？复读机？忍者！ “躺好吧！”js 老大拿起一旁的咖啡，对函数说道。 “好！” js 老大按下工作台旁的按钮，函数眼中射出两道光芒，投在了工作台前的白幕。工作台一旁，出现了一个小盆，里面空空如也。 “来吧，开始执行！”老大狠狠的抿了一口手中的咖啡，按下了工作台侧边的按钮。 嘿！你好 工作台上方的白幕上出现了函数保存的第一行代码： let num1 = 1; 老大大手一挥，造了个新数据：1，分配到了变量大厅的 0x007 号单间，于此同时工作台旁的小盆内出现了一个身影，头上标着 num1，身上写着 0x007。 “嘿！小不点，你好呀！”老大对刚出现的身影挥了挥手。 “你才是小不点！” num1 挥了挥那只小手，呛了老大一句。 老大嘿嘿一笑，摇了摇头。“不管你了，继续执行！
browser
烦死了！ “你说你们人类烦不烦！前几天就一直在打开这个网页，今天又打开了！这个网页啊！” 说着 javascript 老大 拍了拍自己的脑袋，叹道：“哎，这个网页的 javascript 执行任务，我实在是不想接了！这样子下去，我的头发可不保咯！” “哎！算了！谁让我不是浏览器的老大呢，干活，干活！” javascript 老大拿起一旁的的 javascript 语法解释器，将 html 解析器 送过来的 javascript 文本解释并执行了起来。 不一会，空荡荡的变量大厅开始有了声响，声音逐渐变的嘈杂起来，甚至传出了吵闹声！ 执行大厅的大屏幕上也充斥着当前执行大厅各种各样的信息。 焦急 “叮铃 ~ 叮铃 ~ 叮铃 ~ ” 一旁的电话突然响了起来，js 老大顺手按下了免提。 “怎么这么慢啊！这都过去好几秒了！我这边还等着解析 html 呢！” 电话一头穿来了
browser
警告 “警告！警告！警告！” JavaScript 执行大厅传出了刺耳的警告声。 “报告：内存即将溢出，请及时清理无效的内存占用，释放资源！” 伴随着阵阵的警告铃声，大厅正中的大屏幕上显示出了警告信息。 “什么情况？这页面才打开了一会会，内存的消耗就这么大？这都已经去了好几次了！” JavaScript 主线程，也就是 JavaScript 执行大厅的老大疑惑的说道：“看来又得去变量大厅瞧瞧了！” 说着，JavaScript 主线程放下了手头的工作，赶忙往 变量大厅 走去。 变量大厅 “挤死了，你过去点！” 还未到 变量大厅 的 JavaScript 老大远远就听到了这骂骂咧咧的声音。 “不行啊，那边已经挤满了变量！” “挤一挤啊，我这半只脚还在外面呢！” “什么！你在说一遍！太吵了听不清！” JavaScript 老大发现事情即将恶化，要是在不及时清理的话，这些变量就要反了，下意识的 JavaScript 主线程跑了起来。
browser
还能更快！ “咚咚咚” 浏览器老大的门被敲响了三次，“谁啊！” “我！” TCP 喊道，“还有我！” HTTP 随后接道。 “进来吧，都有什么事啊？” 说着，浏览器老大放下了手头的工作。 “你来说吧！毕竟是你想到的。” TCP 对 HTTP 说道。 “那我就不客气了！老大，还记得之前提的让请求变快的方式吗？” “当然，首先是缓存，然后是长连接，接着你们自己还定了个 pipelining 对吧？怎么啦？难不成又有新发现！” 浏览器老大两眼开始放光。 “emmm 那个 pipelining 不是很好用。不过确实，我们有新发现！这几天，我和 TCP 仔仔细细的研究了下发现还可以提升，这不是过来和你讨论讨论！” HTTP 显得有点兴奋。 回忆 故事开始在一周前。 “TCP 你提的这个 pipelining
browser
来客 时间定格在早上 6 点，伴随着 “哒哒哒” 的声响，浏览器地址栏出现了 https://breeze.red 浏览器知道，又是一个早高峰来袭。 “各部门就绪！” 浏览器老大，一声令下，各部门都开始做起了准备工作。 “去 HTTP 服务部，记住你的请求方式是 GET，还有这些请求头也一起拿走。” 伴随着 Enter 的输入，浏览器老大对新生成的 URL 说道。 “浏览器老大让我来找你！” URL 飞奔到我的办公室说道。 “好，请求方式？” 我一看时间，早上 6 点，知道早高峰即将来临，赶忙说道。 “GET” “请求头有吗？” “有！URL 拿出一个袋子说道。” “OK” 说着，我拿起放在一旁的麻醉针，一针下去，URL
browser
圆桌会议 “又到了一月一次的总结大会，大家说说最近工作上出现的问题吧。” 浏览器老大坐在圆桌最前端，说道：“好意见赶紧提，吐槽也可以说。” “我！我！我！” TCP 喊道。 “嗯，你说。” “上次你们优化请求，怎么没叫上我呢？对于请求速度优化我也有点想法！” TCP 说道。 “上次啊，我其实也就是到 HTTP 那儿抱怨了一句，主要还是 HTTP 和他服务器的朋友一起弄好的。” 浏览器老大看了 HTTP 一眼，眼中满是得意，转头看向 TCP 说道：“说说你的想法吧。” “上次你们弄缓存时，我也仔细的查看了一下通过我发送的报文，总结出来一个规律。” 说着 TCP 拿出了事先准备好的一张图，并投到了圆桌对面的屏幕上。 “大家请看，这是用户打开 https://breeze.red 时，通过我发送的一系类请求，我按域名进行了分类。” 说着