css 有时候会很棘手，尤其是在定位和设置大小的时候。本文包含了我整理的一系列有用的片段，它们使我的生活变得更容易，希望也能帮到你们。注：每个段落的下方有一个表，说明浏览器的支持情况。定位水平和垂直方向动态调整大小的元素。.parent { position: relative; } .child { position: absolute; left: 50%; top: 50% -webkit-transform: translate(-50%, -50%); -moz-transform: translate(-50%, -50%); -ms-transform: translate(-50%, -50%); -o-transform: translate(-50%, -50%); transform: translate(-50%, -50%); }固定大小的元素。.parent { position: relative; } .child { position: absolute; left: 50%; top: 50% height: 250px; width: 500px; /* Translate element based on it's s ...继续阅读 (7)

讨论jQuery和javascript性能的文章并不罕见。然而，本文我计划总结一些速度方面的技巧和我本人的一些建议，来提升你的jQuery和javascript代码。好的代码会带来速度的提升。快速渲染和响应意味着更好的用户体验。首先，在脑子里牢牢记住jQuery就是javascript。这意味着我们应该采取相同的编码惯例,风格指南和最佳实践。首先，如果你是一个javascript新手，我建议您阅读 《给JavaScript初学者的24条最佳实践》 ,这是一篇高质量的javascript教程，接触jQuery之前最好先阅读。当你准备使用jQuery,我强烈建议你遵循下面这些指南:缓存变量DOM遍历是昂贵的，所以尽量将会重用的元素缓存。// 糟糕 h = $('#element').height(); $('#element').css('height',h-20); // 建议 $element = $('#element'); h = $element.height(); $element.css('height',h-20);避免全局变量jQuery与javascript一样，一般来说,最好确保你的变量在函数作用域内。// 糟糕 $element = $('#element'); h = $element.height(); $element.css('height',h ...继续阅读 (19)

讨论jQuery和javascript性能的文章并不罕见。然而，本文我计划总结一些速度方面的技巧和我本人的一些建议，来提升你的jQuery和javascript代码。好的代码会带来速度的提升。快速渲染和响应意味着更好的用户体验。首先，在脑子里牢牢记住jQuery就是javascript。这意味着我们应该采取相同的编码惯例,风格指南和最佳实践。首先，如果你是一个javascript新手，我建议您阅读 《给JavaScript初学者的24条最佳实践》 ,这是一篇高质量的javascript教程，接触jQuery之前最好先阅读。当你准备使用jQuery,我强烈建议你遵循下面这些指南:缓存变量DOM遍历是昂贵的，所以尽量将会重用的元素缓存。// 糟糕 h = $('#element').height(); $('#element').css('height',h-20); // 建议 $element = $('#element'); h = $element.height(); $element.css('height',h-20);避免全局变量jQuery与javascript一样，一般来说,最好确保你的变量在函数作用域内。// 糟糕 $element = $('#element'); h = $element.height(); $element.css('height',h ...继续阅读 (7)

在 javascript 代码中，因为各浏览器之间的行为的差异，我们经常会在函数中包含了大量的if语句，以检查浏览器特性，解决不同浏览器的兼容问题。 例如，我们最常见的为dom节点添加事件的函数：function addEvent (type, element, fun) { if (element.addEventListener) { element.addEventListener(type, fun, false); } else if(element.attachEvent){ element.attachEvent('on' + type, fun); } else{ element['on' + type] = fun; } }每次调用addEvent函数的时候，它都要对浏览器所支持的能力进行检查，首先检查是否支持addEventListener方法，如果不支持，再检查是否支持attachEvent方法，如果还不支持，就用 dom 0 级的方法添加事件。 这个过程，在addEvent函数每次调用的时候都要走一遍，其实，如果浏览器支持其中的一种方法，那么他就会一直支持了，就没有必要再进行其他分支的检测了， 也就是说，if语句不必每次都执行，代码可以运行的更快一些。解决的方案就 ...继续阅读 (34)

在 javascript 代码中，因为各浏览器之间的行为的差异，我们经常会在函数中包含了大量的if语句，以检查浏览器特性，解决不同浏览器的兼容问题。 例如，我们最常见的为dom节点添加事件的函数：function addEvent (type, element, fun) { if (element.addEventListener) { element.addEventListener(type, fun, false); } else if(element.attachEvent){ element.attachEvent('on' + type, fun); } else{ element['on' + type] = fun; } }每次调用addEvent函数的时候，它都要对浏览器所支持的能力进行检查，首先检查是否支持addEventListener方法，如果不支持，再检查是否支持attachEvent方法，如果还不支持，就用 dom 0 级的方法添加事件。 这个过程，在addEvent函数每次调用的时候都要走一遍，其实，如果浏览器支持其中的一种方法，那么他就会一直支持了，就没有必要再进行其他分支的检测了， 也就是说，if语句不必每次都执行，代码可以运行的更快一些。解决的方案就 ...继续阅读 (7)

在软件开发领域，前端工程师曾经是一个比较纠结的职业。 在 Web 技术真正发展起来之前的相当长一段时间里，由于技术门槛很低，前端工程师行业一直是鱼龙混杂的状态。 其中很多号称是 Web 开发者的人实际上并没有什么专业的前端技能，有些工作就是被当做简单的力气活由美术设计师顺便做做而已。 当时很多人甚至并不认为有朝一日会有这么一群人用 HTML、CSS 和 JavaScript 这三门技术谋生——他们想，这怎么可能呢——这些技术看起来都是如此简单， 随随便便混在一起用就哦了，把做这些活看成一种正儿八经的职业简直是笑话。随着技术发展，人们对前端工作的看法开始改变了，一些人从美工页面仔真正转变为专业的前端工程师。 JavaScript，这门很多工程师曾经把它当做玩具而不屑一顾的脚本语言悄然演变成推动互联网发展的核心驱动力。 伴随着越来越多的浏览器的出现使得用 HTML 和 CSS 兼容各种浏览器变得越来越难，于是能实现兼容各种浏览器的页面成为了前端工程师的金字招牌，前端职业开始变得炙手可热。两个独立的 UI 层即使 Ajax 这种技术风靡全球之后，前端工程师的主要工作曾经也仅局限于浏览器窗口之内。 HTML、CSS 和 JavaScript 是前端工程师必须要掌握的三种核心技术，前端同后端的唯一交集仅仅是前端需要确保后端的数据能够以正确合适的格式输出到浏览器上。 在某种意义上来说，Web ...继续阅读 (20)

在软件开发领域，前端工程师曾经是一个比较纠结的职业。 在 Web 技术真正发展起来之前的相当长一段时间里，由于技术门槛很低，前端工程师行业一直是鱼龙混杂的状态。 其中很多号称是 Web 开发者的人实际上并没有什么专业的前端技能，有些工作就是被当做简单的力气活由美术设计师顺便做做而已。 当时很多人甚至并不认为有朝一日会有这么一群人用 HTML、CSS 和 JavaScript 这三门技术谋生——他们想，这怎么可能呢——这些技术看起来都是如此简单， 随随便便混在一起用就哦了，把做这些活看成一种正儿八经的职业简直是笑话。随着技术发展，人们对前端工作的看法开始改变了，一些人从美工页面仔真正转变为专业的前端工程师。 JavaScript，这门很多工程师曾经把它当做玩具而不屑一顾的脚本语言悄然演变成推动互联网发展的核心驱动力。 伴随着越来越多的浏览器的出现使得用 HTML 和 CSS 兼容各种浏览器变得越来越难，于是能实现兼容各种浏览器的页面成为了前端工程师的金字招牌，前端职业开始变得炙手可热。两个独立的 UI 层即使 Ajax 这种技术风靡全球之后，前端工程师的主要工作曾经也仅局限于浏览器窗口之内。 HTML、CSS 和 JavaScript 是前端工程师必须要掌握的三种核心技术，前端同后端的唯一交集仅仅是前端需要确保后端的数据能够以正确合适的格式输出到浏览器上。 在某种意义上来说，Web ...继续阅读 (7)

在Wealthfront我们是一个函数式编程的超级粉丝。强调不变性和函数式风格意味着更少的“意外”(surprises)，因为副作用是有限的或不存在的。我们能将独立的组件迅速构建出大型系统，通过组合的方式组合组件。函数式编程原则直接应用在大多数语言中，即使他们不是被定义为函数式。同样适用非函数式的css。让我们看下我们最喜欢的(和最讨厌的)一些特性在样式语言中。一切都是全局作用域。一切都是可变的。优先级的计算，基于一些有趣的规则。因此让我们讨论下我们能做什么。Wealthfront的 CSS(实际是 SCSS)风格指南概述一些经验法则，让我们在CSS中获得函数式编程范式的效益。确切的说，指南通过限制副作用减少意外，提倡组合使我们的样式表更具伸缩性。在本文中,我将介绍一些我们的样式指南中的主要的规则。引入作用域大部分语言中，变量定义被限制在它们的作用域内。在Javascript中，变量的作用域是他们所在的函数，而其他语言中，如Java变量具有块级作用域。我在我的作用域里定义的变量不能被其他人在我的作用域外重定义或修改。作用域是防御式编程和降低副作用的重要部分。如果您的规则、函数或变量只存在于一个受限的作用域，那么你可以放心没人会更改它，无论是有意还是无意的。CSS没有作用域。样式定义时可能意外重写其他规则，而且无法保证你挑选的样式规则名称没被其他人使用。它可能在完全不同的文件里，并且 ...继续阅读 (21)

在Wealthfront我们是一个函数式编程的超级粉丝。强调不变性和函数式风格意味着更少的“意外”(surprises)，因为副作用是有限的或不存在的。我们能将独立的组件迅速构建出大型系统，通过组合的方式组合组件。函数式编程原则直接应用在大多数语言中，即使他们不是被定义为函数式。同样适用非函数式的css。让我们看下我们最喜欢的(和最讨厌的)一些特性在样式语言中。一切都是全局作用域。一切都是可变的。优先级的计算，基于一些有趣的规则。因此让我们讨论下我们能做什么。Wealthfront的 CSS(实际是 SCSS)风格指南概述一些经验法则，让我们在CSS中获得函数式编程范式的效益。确切的说，指南通过限制副作用减少意外，提倡组合使我们的样式表更具伸缩性。在本文中,我将介绍一些我们的样式指南中的主要的规则。引入作用域大部分语言中，变量定义被限制在它们的作用域内。在Javascript中，变量的作用域是他们所在的函数，而其他语言中，如Java变量具有块级作用域。我在我的作用域里定义的变量不能被其他人在我的作用域外重定义或修改。作用域是防御式编程和降低副作用的重要部分。如果您的规则、函数或变量只存在于一个受限的作用域，那么你可以放心没人会更改它，无论是有意还是无意的。CSS没有作用域。样式定义时可能意外重写其他规则，而且无法保证你挑选的样式规则名称没被其他人使用。它可能在完全不同的文件里，并且 ...继续阅读 (10)

javascript中的作用域(scope)和上下文(context)是这门语言的独到之处，这部分归功于他们带来的灵活性。每个函数有不同的变量上下文和作用域。这些概念是javascript中一些强大的设计模式的后盾。然而这也给开发人员带来很大困惑。下面全面揭示了javascript中的上下文和作用域的不同，以及各种设计模式如何使用他们。上下文 vs 作用域首先需要澄清的问题是上下文和作用域是不同的概念。多年来我注意到许多开发者经常将这两个术语混淆，错误的将一个描述为另一个。平心而论，这些术语变得非常混乱不堪。每个函数调用都有与之相关的作用域和上下文。从根本上说，范围是基于函数(function-based)而上下文是基于对象(object-based)。换句话说，作用域是和每次函数调用时变量的访问有关，并且每次调用都是独立的。上下文总是关键字 this 的值，是调用当前可执行代码的对象的引用。变量作用域变量能够被定义在局部或者全局作用域，这导致运行时变量的访问来自不同的作用域。全局变量需被声明在函数体外，在整个运行过程中都存在，能在任何作用域中访问和修改。局部变量仅在函数体内定义，并且每次函数调用都有不同的作用域。这主题是仅在调用中的赋值，求值和对值的操作，不能访问作用域之外的值。目前javascript不支持块级作用域，块级作用域指在if语句，switch语句，循环语句等语句块中 ...继续阅读 (13)

为什么会用这样一个题目呢，这是要说封装的什么问题，本文并不讲高深的封装理论，只是解决一个小问题。问题来源今天在百度知道上闲逛，遇到一个网友的问题，问题如下，问题的地址见这里：下面先不看看其他网友给的答案：网友大部分回答不能一起定义，那么我们来分析下为什么这样做是错的，然后给出相应的解决办法。重现问题先来说说为什么调用出错，我在自己的浏览器里重现了问题，处于实验并未全部复原代码，并且用到了全局变量哦:function Dialog(){ Dialog.prototype = { init:function(){ console.log("ok"); } } } var a = new Dialog(); a.init();下面是火狐提示的错误：分析问题init不是一个方法，这是为什么呢，我们将调用代码修改下，出于演示，并未遵循JsLint代码规范：var a = new Dialog(); typeof a.init;结果显示为undefined，也就是init没有被定义，或者说在求值过程中未找到init标识符的值，这是因为在调用函数时函数里面的内容才会被解析执行，所以在调用new Dialog()，时其内部的代码尚未执行，所以设置Dialog的原型的语句尚未执行，通过这个例子可以看出绑定this的p ...继续阅读 (28)

javascript中的作用域(scope)和上下文(context)是这门语言的独到之处，这部分归功于他们带来的灵活性。每个函数有不同的变量上下文和作用域。这些概念是javascript中一些强大的设计模式的后盾。然而这也给开发人员带来很大困惑。下面全面揭示了javascript中的上下文和作用域的不同，以及各种设计模式如何使用他们。上下文 vs 作用域首先需要澄清的问题是上下文和作用域是不同的概念。多年来我注意到许多开发者经常将这两个术语混淆，错误的将一个描述为另一个。平心而论，这些术语变得非常混乱不堪。每个函数调用都有与之相关的作用域和上下文。从根本上说，范围是基于函数(function-based)而上下文是基于对象(object-based)。换句话说，作用域是和每次函数调用时变量的访问有关，并且每次调用都是独立的。上下文总是关键字 this 的值，是调用当前可执行代码的对象的引用。变量作用域变量能够被定义在局部或者全局作用域，这导致运行时变量的访问来自不同的作用域。全局变量需被声明在函数体外，在整个运行过程中都存在，能在任何作用域中访问和修改。局部变量仅在函数体内定义，并且每次函数调用都有不同的作用域。这主题是仅在调用中的赋值，求值和对值的操作，不能访问作用域之外的值。目前javascript不支持块级作用域，块级作用域指在if语句，switch语句，循环语句等语句块中 ...继续阅读 (8)

为什么会用这样一个题目呢，这是要说封装的什么问题，本文并不讲高深的封装理论，只是解决一个小问题。问题来源今天在百度知道上闲逛，遇到一个网友的问题，问题如下，问题的地址见这里：下面先不看看其他网友给的答案：网友大部分回答不能一起定义，那么我们来分析下为什么这样做是错的，然后给出相应的解决办法。重现问题先来说说为什么调用出错，我在自己的浏览器里重现了问题，处于实验并未全部复原代码，并且用到了全局变量哦:function Dialog(){ Dialog.prototype = { init:function(){ console.log("ok"); } } } var a = new Dialog(); a.init();下面是火狐提示的错误：分析问题init不是一个方法，这是为什么呢，我们将调用代码修改下，出于演示，并未遵循JsLint代码规范：var a = new Dialog(); typeof a.init;结果显示为undefined，也就是init没有被定义，或者说在求值过程中未找到init标识符的值，这是因为在调用函数时函数里面的内容才会被解析执行，所以在调用new Dialog()，时其内部的代码尚未执行，所以设置Dialog的原型的语句尚未执行，通过这个例子可以看出绑定this的p ...继续阅读 (8)

在学习javascript的过程中，许多新手发现很难弄明白javascript复杂的的原型继承工作机制。在这篇文章中我谈谈在通过父函数的原型继承模型中如何实现实例属性。一个简单的Widget 对象在下面的代码中，我们有个一父类 Widget，父类有个属性 messages和父类为Widget的SubWidget类。在这种情况下我们想让SubWidget的每个实例在初始化的时候一个空的消息数组:var Widget = function( name ){ this.messages = []; }; Widget.prototype.type='Widget'; var SubWidget = function( name ){ this.name = name; Widget.apply( this, Array.prototype.slice.call( arguments ) ); }; SubWidget.prototype = new Widget();在我们设置SubWidget 的原型为Widget的一个实例之前，对象的关系图如下：代码最后一行将SubWidget的父类设置为Widget类的一个实例，”new”关键字背后，创建了继承树并且绑定了对象的原型链，现在我们的对象关系图看起来像下面这样：你看出问题所在了吗？让我们创建子类的实例凸显问题：var ...继续阅读 (19)

在学习javascript的过程中，许多新手发现很难弄明白javascript复杂的的原型继承工作机制。在这篇文章中我谈谈在通过父函数的原型继承模型中如何实现实例属性。一个简单的Widget 对象在下面的代码中，我们有个一父类 Widget，父类有个属性 messages和父类为Widget的SubWidget类。在这种情况下我们想让SubWidget的每个实例在初始化的时候一个空的消息数组:var Widget = function( name ){ this.messages = []; }; Widget.prototype.type='Widget'; var SubWidget = function( name ){ this.name = name; Widget.apply( this, Array.prototype.slice.call( arguments ) ); }; SubWidget.prototype = new Widget();在我们设置SubWidget 的原型为Widget的一个实例之前，对象的关系图如下：代码最后一行将SubWidget的父类设置为Widget类的一个实例，”new”关键字背后，创建了继承树并且绑定了对象的原型链，现在我们的对象关系图看起来像下面这样：你看出问题所在了吗？让我们创建子类的实例凸显问题：var ...继续阅读 (6)

绝大多数的网站都在使用一个网格。 他们可能没有明确的使用网格系统，但如果他们有一个向左浮动“主要内容区”和一个向右浮动的“侧边栏”，这就是一个简单的网格。如果需要更复杂的布局，人们往往会借助框架。 他们猜想网格是超高难度的事情最好留给超级CSS书呆子。 这一理念导致这样的事实，很多网格系统是非常复杂的 。下面是我如何构建网格。 它一点都不难也不复杂。 甚至使他们灵活也不是一个大的任务。容器块级元素的宽度和它的父元素一样（ width: auto; ）。 我们可以把它的宽度看作是100%。 wrapper 对于网格可能语义不太好，但它只是一个普通的包装器，所以div是合适的。100% wide列让我们从一个实用的，通用的需要开始：主要内容区宽度为2/3和1/3宽的侧边栏。 我们只用2个div元素代表两列并取的适当的类名。Main ContentSidebar为了让他们水平排列，我们只需要浮动他们并设置合适的宽度。 我们选择他们像下面这样：[class*='col-'] { float: left; }各个宽度的设置像下面这样：.col-2-3 { width: 66.66%; } .col-1-3 { width: 33.33%; }这就是全部的前提关于简单网格。给容器清除浮动父元素会发生坍塌高度变为0，因为它的子元素全部浮动，浮动的元素将脱离标准流。 下面让我们修补这种 ...继续阅读 (18)

今天在web上任何大一点的网站或应用程序都包含大量的html，css和javascript。随着互联网的发展和我们对互联网越来越依赖，计划组织和维护你的前端代码是绝对必要的。今天大一点的web公司，越来越多的人接触越到比例越来越大的前端代码。因此,大多数公司努力保持他们的代码模块化。改变一个应用程序的一部分经常无意中影响到看似不相关的其他部分。防止意外的影响不是一个容易解决的问题,特别是由于HTML、CSS和JavaScript本身是相互关联的。更糟糕的是,传统的计算机科学原则如分离关注点,一直是服务器端开发的一部分,却很少被讨论在前端代码中。在本文中,我将谈谈我是如何学会分离我的HTML、CSS和JavaScript。据我的经验和我所知道的其他人的经验,完成目标的最好的方式是不明显,反直觉的,有时不利于大量所谓的“最佳实践”的。目标HTML、CSS和JavaScript之间总是会有一些耦合。不管怎样,这些技术被用来互相作用。举个例子,一个fly-in transition(飞入变换)可能在样式表中定义了一个类选择器,但它通常是由用户交互来触发,通过JavaScript来执行，并且通过在html中添加一个类来初始化。由于在你的前端代码中存在一些耦合是不可避免的。你的目标不应该是简单地完全消除耦合，而应该是最小化耦合,使这部分代码不必依赖其他部分。后端开发人员应该能够改变HTML模板 ...继续阅读 (15)

今天在web上任何大一点的网站或应用程序都包含大量的html，css和javascript。随着互联网的发展和我们对互联网越来越依赖，计划组织和维护你的前端代码是绝对必要的。今天大一点的web公司，越来越多的人接触越到比例越来越大的前端代码。因此,大多数公司努力保持他们的代码模块化。改变一个应用程序的一部分经常无意中影响到看似不相关的其他部分。防止意外的影响不是一个容易解决的问题,特别是由于HTML、CSS和JavaScript本身是相互关联的。更糟糕的是,传统的计算机科学原则如分离关注点,一直是服务器端开发的一部分,却很少被讨论在前端代码中。在本文中,我将谈谈我是如何学会分离我的HTML、CSS和JavaScript。据我的经验和我所知道的其他人的经验,完成目标的最好的方式是不明显,反直觉的,有时不利于大量所谓的“最佳实践”的。目标HTML、CSS和JavaScript之间总是会有一些耦合。不管怎样,这些技术被用来互相作用。举个例子,一个fly-in transition(飞入变换)可能在样式表中定义了一个类选择器,但它通常是由用户交互来触发,通过JavaScript来执行，并且通过在html中添加一个类来初始化。由于在你的前端代码中存在一些耦合是不可避免的。你的目标不应该是简单地完全消除耦合，而应该是最小化耦合,使这部分代码不必依赖其他部分。后端开发人员应该能够改变HTML模板 ...继续阅读 (7)

绝大多数的网站都在使用一个网格。 他们可能没有明确的使用网格系统，但如果他们有一个向左浮动“主要内容区”和一个向右浮动的“侧边栏”，这就是一个简单的网格。如果需要更复杂的布局，人们往往会借助框架。 他们猜想网格是超高难度的事情最好留给超级CSS书呆子。 这一理念导致这样的事实，很多网格系统是非常复杂的 。下面是我如何构建网格。 它一点都不难也不复杂。 甚至使他们灵活也不是一个大的任务。容器块级元素的宽度和它的父元素一样（ width: auto; ）。 我们可以把它的宽度看作是100%。 wrapper 对于网格可能语义不太好，但它只是一个普通的包装器，所以div是合适的。<div class="grid"> <!-- 100% wide --> </div>列让我们从一个实用的，通用的需要开始：主要内容区宽度为2/3和1/3宽的侧边栏。 我们只用2个div元素代表两列并取的适当的类名。<div class="grid"> <div class="col-2-3"> Main Content </div> <div class="col-1-3"> Sidebar </div> </div>为了让他们水平排列，我们只需要浮动他们并设置合 ...继续阅读 (8)

演进和使用的JavaScript是早在1995年开发的一种语言，真的是刚刚起步。网景公司在1995年四月聘请Brendan Eich ，他被告知，他有10天时间创造并制作了一种将在Netscape的浏览器中运行，以原型为工作方式的编程语言。那时候，Web创新的步伐是激烈的，由于微软突然使互联网的焦点集中在它即将发布的Windows 95操作系统作为对新兴Netscape的浏览器和服务器产品的系统发布的回应。当时网景得到如此多的来自微软的关注，因为网景考虑将Web浏览器和服务器作为一个分布式操作系统一种新形式，而不仅仅是一个单一的应用程序的。自从Mosaic在1993年首次亮相，网络便成为可移植的，跨越Windows，Macintosh和Unix，并给了软件开发者他们可以为所有这些环境中开发应用程序的希望。但是，仅凭HTML本身去定义一个新的应用程序开发环境或操作系统，是远远不够。为了巩固便携式操作系统的概念，网络和网景公司需要便携式的编程语言。Sun公司的Java语言似乎是便携式重量级应用的解决方案。一种产生的字节代码并运行在Java虚拟机中的编译语言，Java支持丰富的来自C++的面向对象的模式并且似乎能够能够实现和Ç++和C相似的性能.Java 是Web对Microsoft的Visual C + +的答案。走进javascript众所周知Java是一个丰富的，复杂的，编译的，专 ...继续阅读 (27)

演进和使用的JavaScript是早在1995年开发的一种语言，真的是刚刚起步。网景公司在1995年四月聘请Brendan Eich ，他被告知，他有10天时间创造并制作了一种将在Netscape的浏览器中运行，以原型为工作方式的编程语言。那时候，Web创新的步伐是激烈的，由于微软突然使互联网的焦点集中在它即将发布的Windows 95操作系统作为对新兴Netscape的浏览器和服务器产品的系统发布的回应。当时网景得到如此多的来自微软的关注，因为网景考虑将Web浏览器和服务器作为一个分布式操作系统一种新形式，而不仅仅是一个单一的应用程序的。自从Mosaic在1993年首次亮相，网络便成为可移植的，跨越Windows，Macintosh和Unix，并给了软件开发者他们可以为所有这些环境中开发应用程序的希望。但是，仅凭HTML本身去定义一个新的应用程序开发环境或操作系统，是远远不够。为了巩固便携式操作系统的概念，网络和网景公司需要便携式的编程语言。Sun公司的Java语言似乎是便携式重量级应用的解决方案。一种产生的字节代码并运行在Java虚拟机中的编译语言，Java支持丰富的来自C++的面向对象的模式并且似乎能够能够实现和Ç++和C相似的性能.Java 是Web对Microsoft的Visual C + +的答案。##走进javascript众所周知Java是一个丰富的，复杂的，编译的 ...继续阅读 (7)

“设计良好的函数往往比较小，而过大函数的设计往往一塌糊涂，或者存在很大的优化空间。”也许你认为讨论函数的大小没有必要，原因是函数设计的本质是内聚，它的大小只是它的表现形式。 而上面的原因有必要让我们讨论一下函数的大小问题。我对函数的核心思路：我提出代码最小处理单元的概念：一个基本操作（赋值，比较等），一个函数调用（包括调用后判断返回值进行判断）都看成一个最小处理单元。 那么，一个函数，最小处理单元合理的个数范围在7以内。 如果超过了7，你就要考虑把他们拆分成多个函数了（为什么是7？人同时能够处理的信息不超过7个）。最小数目没有限制，即便是只有1个，也有存在的必要。在下面的情况下我会将函数拆分为更小的函数：1、一眼不能够看到函数所有的代码。如果函数过长，无法一眼看到一个函数所有的代码，我会毫不犹豫的拆分。 我不想让读者去翻屏，也不想让读者前顾后盼，顾此失彼。漂亮的函数应该让读者一眼就知道他在做什么以及怎么做的。2、局部变量过多。如果局部变量超过七个，我会考虑拆分函数。 变量过多意味着我要记录太多的状态，这会加重我大脑的负担，同时要考虑太多的东西。 这也同时意味着我可能没有对函数功能进行深入的思考。3、太多的缩进。太多的缩进意味着太多的嵌套，要么是循环，要么是判断，都会导致复杂的逻辑。4、不处于同一抽象层次。举例，有一个初始化函数，需要初始化配置数据，套接字，数据库连接，通道状态。Vo ...继续阅读 (18)

“设计良好的函数往往比较小，而过大函数的设计往往一塌糊涂，或者存在很大的优化空间。”也许你认为讨论函数的大小没有必要，原因是函数设计的本质是内聚，它的大小只是它的表现形式。 而上面的原因有必要让我们讨论一下函数的大小问题。我对函数的核心思路：我提出代码最小处理单元的概念：一个基本操作（赋值，比较等），一个函数调用（包括调用后判断返回值进行判断）都看成一个最小处理单元。 那么，一个函数，最小处理单元合理的个数范围在7以内。 如果超过了7，你就要考虑把他们拆分成多个函数了（为什么是7？人同时能够处理的信息不超过7个）。最小数目没有限制，即便是只有1个，也有存在的必要。在下面的情况下我会将函数拆分为更小的函数：1、一眼不能够看到函数所有的代码。如果函数过长，无法一眼看到一个函数所有的代码，我会毫不犹豫的拆分。 我不想让读者去翻屏，也不想让读者前顾后盼，顾此失彼。漂亮的函数应该让读者一眼就知道他在做什么以及怎么做的。2、局部变量过多。如果局部变量超过七个，我会考虑拆分函数。 变量过多意味着我要记录太多的状态，这会加重我大脑的负担，同时要考虑太多的东西。 这也同时意味着我可能没有对函数功能进行深入的思考。3、太多的缩进。太多的缩进意味着太多的嵌套，要么是循环，要么是判断，都会导致复杂的逻辑。4、不处于同一抽象层次。举例，有一个初始化函数，需要初始化配置数据，套接字，数据库连接，通道状态。Vo ...继续阅读 (7)

首先，问“这个问题(英文)”的人是个天才，他怎么会遇到这样的一个问题。 其次，回答这个问题的人更是一个天才，我难以想象他会回答这个问题，更难以想象的是，他的回答是如此的详细和丰富和完整，真正称得上诲人不倦。既然遇到了这个问题，我们不妨也跟着提高一下。这是一个Javascript 语言题目，一个完全有效的等式，不信自己可以试一下，下面看看高人的题解：++[[]][+[]]+[+[]]如果把这段表达式拆分开来，它相等于：++[[]][+[]] + [+[]]在 JavaScript 里，+[] === 0是完全正确的。+会把一些字符转化成数字，在这里，这个式子会变成+""或0。因此，我们可以简化一下(++比+有更高的优先级)：++[[]][0] + [0]因为[[]][0]的意思是：获取[[]]的第一个元素，这就得出了下面的结果：[[]][0]返回内部数组 ([])。根据语言规范，我们说[[]][0] === []是不正确的，但让我们把这个内部数组称作 A，以避免错误的写法。++[[]][0] == A + 1， 因为++的意思是”加一”。++[[]][0] === +(A + 1)；换句话说，你得到的永远是个数值(+1并不一定得到的是个数值，但++一定是)。同样，我们可以把这一堆代码简化的更清晰。让我们把 A 换回成[]:+([] + 1) + [0]在 JavaScript 里，这 ...继续阅读 (12)

首先，问“这个问题(英文)”的人是个天才，他怎么会遇到这样的一个问题。 其次，回答这个问题的人更是一个天才，我难以想象他会回答这个问题，更难以想象的是，他的回答是如此的详细和丰富和完整，真正称得上诲人不倦。既然遇到了这个问题，我们不妨也跟着提高一下。这是一个Javascript 语言题目，一个完全有效的等式，不信自己可以试一下，下面看看高人的题解：++[[]][+[]]+[+[]]如果把这段表达式拆分开来，它相等于：++[[]][+[]] + [+[]]在 JavaScript 里，+[] === 0是完全正确的。+会把一些字符转化成数字，在这里，这个式子会变成+""或0。因此，我们可以简化一下(++比+有更高的优先级)：++[[]][0] + [0]因为[[]][0]的意思是：获取[[]]的第一个元素，这就得出了下面的结果：[[]][0]返回内部数组 ([])。根据语言规范，我们说[[]][0] === []是不正确的，但让我们把这个内部数组称作 A，以避免错误的写法。++[[]][0] == A + 1， 因为++的意思是”加一”。++[[]][0] === +(A + 1)；换句话说，你得到的永远是个数值(+1并不一定得到的是个数值，但++一定是)。同样，我们可以把这一堆代码简化的更清晰。让我们把 A 换回成[]:+([] + 1) + [0]在 JavaScript 里，这 ...继续阅读 (7)

1.DRYDRY 是一个最简单的法则，也是最容易被理解的。 但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力， 这并不是一件容易的事）。它意味着，当我们在两个或多个地方发现一些相似的代码的时候， 我们需要把他们的共性抽象出来，形成一个唯一的新方法，并且改变现有的代码， 让他们以一些合适的参数调用这个新的方法。DRY 这一法则可能是编程界中最通用的法则了。 目前为止，应该没有哪个程序员对这一法则存有异议。 但是，我们却能发现，一些程序在编写单元测试时忘记了这一法则： 让我们想象一下，当你改变一个类的若干接口，如果你没有使用DRY， 那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法， 而是每个test case自己去构造类的实例，那么， 当类的构造函数被改变时，你需要修改多少个test cases啊。 这就是不使用DRY法则所带来的恶果。2.短小的方法至少，我们有下面三个不错的理由要求程序员们写下短小的方法。代码会变得更容易阅读。代码会变得更容易重用（短方法可以减少代码间的耦合程度）代码会变得更容易测试。3.良好的命名规范使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护， 当一个类，一个函数，一个变量的名字达到了那种可以“望文 ...继续阅读 (16)

1.DRYDRY 是一个最简单的法则，也是最容易被理解的。 但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力， 这并不是一件容易的事）。它意味着，当我们在两个或多个地方发现一些相似的代码的时候， 我们需要把他们的共性抽象出来，形成一个唯一的新方法，并且改变现有的代码， 让他们以一些合适的参数调用这个新的方法。DRY 这一法则可能是编程界中最通用的法则了。 目前为止，应该没有哪个程序员对这一法则存有异议。 但是，我们却能发现，一些程序在编写单元测试时忘记了这一法则： 让我们想象一下，当你改变一个类的若干接口，如果你没有使用DRY， 那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法， 而是每个test case自己去构造类的实例，那么， 当类的构造函数被改变时，你需要修改多少个test cases啊。 这就是不使用DRY法则所带来的恶果。2.短小的方法至少，我们有下面三个不错的理由要求程序员们写下短小的方法。代码会变得更容易阅读。代码会变得更容易重用（短方法可以减少代码间的耦合程度）代码会变得更容易测试。3.良好的命名规范使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护， 当一个类，一个函数，一个变量的名字达到了那种可以“望文 ...继续阅读 (11)

1.DRYDRY 是一个最简单的法则，也是最容易被理解的。 但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力， 这并不是一件容易的事）。它意味着，当我们在两个或多个地方发现一些相似的代码的时候， 我们需要把他们的共性抽象出来，形成一个唯一的新方法，并且改变现有的代码， 让他们以一些合适的参数调用这个新的方法。DRY 这一法则可能是编程界中最通用的法则了。 目前为止，应该没有哪个程序员对这一法则存有异议。 但是，我们却能发现，一些程序在编写单元测试时忘记了这一法则： 让我们想象一下，当你改变一个类的若干接口，如果你没有使用DRY， 那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法， 而是每个test case自己去构造类的实例，那么， 当类的构造函数被改变时，你需要修改多少个test cases啊。 这就是不使用DRY法则所带来的恶果。2.短小的方法至少，我们有下面三个不错的理由要求程序员们写下短小的方法。代码会变得更容易阅读。代码会变得更容易重用（短方法可以减少代码间的耦合程度）代码会变得更容易测试。3.良好的命名规范使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护， 当一个类，一个函数，一个变量的名字达到了那种可以“望文 ...继续阅读 (7)

一、引子var a = {n:1}; a.x = a = {n:2}; alert(a.x); // --> undefined看 jQuery 源码 时发现的这种写法。 以上第二句a.x = a = {n:2}是一个连续赋值表达式。 这个连续赋值表达式在引擎内部究竟发生了什么？是如何解释的？二、猜想猜想1：从左到右赋值，a.x先赋值为{n:2}，但随后 a 赋值为{n:2}， 即 a 被重写了，值为{n:2}，新的 a 没有 x 属性，因此为undefined。步骤如下a.x = {n:2}; a = {n:2};这种解释得出的结果与实际运行结果一致，貌似是对的。注意「猜想1」中 a.x 被赋值过。猜想2：从右到左赋值，a 先赋值为{n:2}，a.x发现 a 被重写后(之前 a 是{a:1})，a.x = {n:2}引擎限制a.x赋值，忽略了。步骤如下：a = {n:2}; a.x 未被赋值{n:2}等价于a.x = (a = {n:2})，即执行了第一步，这样也能解释a.x为undefined了。注意「猜想2」中 a.x 压根没被赋值过。三、证明上面两种猜想相信多数人都有，群里讨论呆呆认为是「猜想1」， 我认为是「猜想2」。其实都错了。 我忽略了引用的关系。如下，加一个变量 b，指向 a。var a = {n:1}; var b = a; // 持有a，以回查 ...继续阅读 (24)

一、引子var a = {n:1}; a.x = a = {n:2}; alert(a.x); // --> undefined看 jQuery 源码 时发现的这种写法。 以上第二句a.x = a = {n:2}是一个连续赋值表达式。 这个连续赋值表达式在引擎内部究竟发生了什么？是如何解释的？二、猜想猜想1：从左到右赋值，a.x先赋值为{n:2}，但随后 a 赋值为{n:2}， 即 a 被重写了，值为{n:2}，新的 a 没有 x 属性，因此为undefined。步骤如下a.x = {n:2}; a = {n:2};这种解释得出的结果与实际运行结果一致，貌似是对的。注意「猜想1」中 a.x 被赋值过。猜想2：从右到左赋值，a 先赋值为{n:2}，a.x发现 a 被重写后(之前 a 是{a:1})，a.x = {n:2}引擎限制a.x赋值，忽略了。步骤如下：a = {n:2}; a.x 未被赋值{n:2}等价于a.x = (a = {n:2})，即执行了第一步，这样也能解释a.x为undefined了。注意「猜想2」中 a.x 压根没被赋值过。三、证明上面两种猜想相信多数人都有，群里讨论呆呆认为是「猜想1」， 我认为是「猜想2」。其实都错了。 我忽略了引用的关系。如下，加一个变量 b，指向 a。var a = {n:1}; var b = a; // 持有a，以回查 ...继续阅读 (14)