javascript中的this含义非常丰富，它可以是全局对象，当前对象或者是任意对象，这都取决于函数的调用方式。函数有以下几种调用方式：作为对象方法调用、作为函数调用、作为构造函数调用、apply或call调用。

对象方法调用

作为对象方法调用的时候，this会被绑定到该对象。

var point = { 
 x : 0, 
 y : 0, 
 moveTo : function(x, y) { 
     this.x = this.x + x; 
     this.y = this.y + y; 
     } 
 }; 

 point.moveTo(1, 1)//this 绑定到当前对象，即 point 对象

在开发项目组里面，前端一般都是作为一个统称而存在，很多刚毕业的童鞋就问我想从事前端方面问我怎么看，我会反问你对前端了解多少，很多人都认为前端基本上都是搞设计从事视觉方面。

前端从整个项目划分来看，可以分为UE、页面、逻辑，以下逐分析。

一、UE

如果只需要知道一种编程语言就可以构建一个全栈的应用程序，是不是特别了不起？Ryan Dahl为了把这个想法成为现实，创造了node.js。Node.js是建立在Chrome强劲的V8 JavaScript引擎上的服务器端框架。虽然最初是用C++编写的，但是应用程序通过JavaScript运行。

这样一来，问题就解决了。一种语言就可以统治一切。而且，在整个应用程序中你只需要使用这一种语言。所以，我们需要深刻了解node.js。这就是本文的主题。

下面这四个基本概念是你想要掌握node.js所必需的。我会尽可能长话短说向大家介绍它们。

如何定义牛逼工程师

有软件工程方面的研究说，对于开发者个体而言，最优秀的开发者的生产效率约为平均值的2倍，而优秀的开发者会吸引其它优秀的人，或者激励与帮助团队中的其它成员，最终使团队之间的生产效率差异达到10倍之多。

所谓牛逼的工程师，就是那些个体效率是其它人2倍，形成团队之后达到10倍差异的一群人。

前端领域这几年发展速度非常快，人才分布呈两级分化趋势，大家都在说缺前端，其实缺的是牛逼前端，对于低端的前端，培训机构一直在量产，但是无法满足要求。很多情况下，一个牛逼前端对于团队的价值是再多低端前端都无法提供的。

牛逼的前端工程师有一些共通的特质，这些特质也许不属于前端的核心范畴，但是可以通过它们将牛逼的人识别出来。

对用户体验的追求

举例

我们先从示例应用程序的一些摘录开始。下面是暴露Person对象的响应信息库。很类似于传统的，非响应信息库，只不过它返回Flux<Person>而传统的返回List<Person>，以及返回Mono<Person>的地方返回Person。Mono<Void>用作完成标识：指出何时保存被完成。关于Reactor类型的更多信息，请参阅

public interface PersonRepository { Mono<Person> getPerson(int id); Flux<Person> allPeople(); Mono<Void> savePerson(Mono<Person> person);
}

下面是我们如何暴露带有新的函数式web框架的资源库：

RouterFunction<?> route = route(GET("/person/{id}"),
    request -> {
        Mono<Person> person = Mono.justOrEmpty(request.pathVariable("id"))
            .map(Integer::valueOf)
            .then(repository::getPerson); return Response.ok().body(fromPublisher(person, Person.class));
    })
    .and(route(GET("/person"),
        request -> {
            Flux<Person> people = repository.allPeople(); return Response.ok().body(fromPublisher(people, Person.class));
    }))
    .and(route(POST("/person"),
    request -> {
        Mono<Person> person = request.body(toMono(Person.class)); return Response.ok().build(repository.savePerson(person));
}));

下面我们要介绍如何运行，比如在Reactor Netty中：

前言

生活有度，人生添寿。

Javascript从当初的一个“弹窗语言”，一步步发展成为现在前后端通吃的庞然大物。javascript的受欢迎程度也是与日俱增，今年编程语言又是花落javascript，这实在是一个充满了活力的语言。如今，随随便一个网页javascript代码量都不下数千行，要是node后端那更不止几千行了。（WTF）代码量的增加给编程带来的首要的问题就是如何去编写和维护如此庞大的代码呢？答案就是模块化思想，其实就是面向对象（OOP）编程，如今比较流行的三大前端框架（angular,react,vue）基本都实现了组件化编程，但组件化和我们所说的模块化又有所不同，应该可以这么理解，组件化是模块化的升级版，模块化是组件化的基础。那么，问题来了，javascript怎么面向对象编程呢？我想这很多老鸟也不定说的清楚吧，前端杂而活跃的各种社区，很多前端er一度依赖各种插件，根本不需要去了解这些深层的东西却照样能完成任务。但我想作为一个有追求的前端er还是很有必要去学习这些看似用不着的东西的，别的不说，就单单因为我们是前端er,只会用jquery一个稍微厉害的后端都能代替你。好吧，废话不多说，到底如何面向对象coding呢…..

很不幸，es5中并没有给出明确的定义‘类’的概念，所以传统的面向对象编程似乎是行不通的，那么又该肿么办呢？值得庆幸的是，前辈们通过不断探索总结，成功的用javascript模拟出了“类”。那么，javascript的类又该怎么定义呢？

在面向对象编程中，类（class）是对象（object）的模板，定义了同一组对象（又称”实例”）共有的属性和方法。

问题提出

font-weight的属性值有100、200、300、400、500、600、700、800、900和normal、bold、lighter、bolder，它们的区别是？
另外，在实际开发中，我们应该使用数值表达还是文字表达呢？

认识font-weight

根据W3C Fonts节章的规范标准，可知：

前言

React 好像已经火了很久很久，以致于我们对于 Virtual DOM 这个词都已经很熟悉了，网上也有非常多的介绍 React、Virtual DOM 的文章。但是直到前不久我专门花时间去学习 Virtual DOM，才让我对 Virtual DOM 有了一定的理解，以致于要怀疑起很久之前看过的那些文章来。倒不是这些文章讲得不对，而是现在在我看来角度不太好，说得越多，越说不清。

让我能够有所开窍（自认为）的，是这篇文章：

Change And Its Detection In JavaScript Frameworks
Monday Mar 2, 2015 by Tero Parviainen

作者看问题的角度很棒，从数据变更与UI同步的角度来介绍各个典型框架，特别是对于 React 的 Virtual DOM，从这个角度理解起来更容易些。

什么是 rem

可能在你使用收音机或者用其他音乐播放器之前，就已经听过“R.E.M.”这个词了。在这个乐队眼中，这个词是“浅睡眠时眼球的快速转动”的缩写，而在 css 中，rem 代表着“以根元素为参照物的 em 单位“。他不会让你抛弃你的宗教信仰也不会让你相信那个远在月球的人，但是它可以帮助你实现一个和谐、平稳的设计。

根据 W3C 规范中对 1rem 的定义：

1rem 与等于根元素 font-size 的计算值。当明确规定根元素的 font-size 时，rem 单位以该属性的初始值作参照。

WEB服务器、应用程序服务器、HTTP服务器有何区别？IIS、Apache、Tomcat、Weblogic、WebSphere 都各属于哪种服务器？这些问题困惑了很久，今天终于梳理清楚了：

Web服务器的基本功能就是提供Web信息浏览服务。它只需支持HTTP协议、HTML文档格式及URL。与客户端的网络浏览器配合。因为Web服务器主要支持的协议就是HTTP，所以通常情况下HTTP服务器和WEB服务器是相等的(有没有支持除HTTP之外的协议的web服务器，作者没有考证过)，说的是一回事。

应用程序服务器(简称应用服务器)，我们先看一下微软对它的定义：”我们把应用程序服务器定义为“作为服务器执行共享业务应用程序的底层的系统软件”。 就像文件服务器为很多用户提供文件一样，应用程序服务器让多个用户可以同时使用应用程序（通常是客户创建的应用程序）”

通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说:Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。