WebStorm 4 spaces

Pocket 我专门用来看博文。

大厂子就可以不贴薪酬范围了？

网站傻逼了

@otakustay 对啊，JS最难的地方其实在于“怎样用C++/Java/C#的思维方式来思考JS”，可惜很多半路转职的开发者在这一点上越陷越深。


@Tankpt 不错，都是对的。不过我觉得图画得太复杂了。“对象的 __proto__ 指向它构造函数的 prototype”这一句话就能解释那几张图了。

oTest1 是个对象，那么它的 __proto__ 指向构造函数 fTest 的 prototype;
构造函数 fTest 的 prototype 也是个对象，其 __proto__ 指向构造函数 Object 的 prototype;
依此类推。

腾讯是不会的。除非你的成就足够高，能直接引起马化腾的重视。

digg reader 还行吧

禁用 JS 嘛

都『很有』

我发现你问的问题都还有代表性啊。不错。

MVC 对于 JS 来说，是舶来品，同时是必需品。
先说为什么是舶来品。因为 MVC 前几年和 JS 一点关系也没有。MVC 常用在后台程序里，PHP 的 MVC 框架多了去了。我就大概的介绍下，我写后台也没写多久。
一般来说 MVC 都有一个 R（Router，即路由），不懂这个概念没关系，先来看看程序员怎么用 Router。
假设我们用 PHP 实现一个 MVC 的 Todo 网站，那么一个熟悉 MVC 的后台开发人员首先要「设计 URL」
http://example.com/todo/list 这个页面用来展示 todo list
http://example.com/todo/add 用于添加 todo
暂且就要这两个URL吧。Router 的作用就是根据 url，找相应的代码来负责响应（Router 本身不负责响应）。

Router 的实现

if url is /todo/list
> then call somebody to show the list page
if url is /todo/add
> then call somebody to show the adding page
if url is /todo/remove

那么谁来当这个 somebody 呢？它就是 Todo 类，这个类有 list 和 add 两个方法。看上去很完美的样子。为什么 Router 不直接做出响应，非要 Todo 类响应呢？分工明确嘛。

这个 Todo 类，被命名为控制器C（为什么叫控制器？因为待会它要控制 Model 和 View）

Todo 的实现

function list
> get all the todo MODELs
> generate a VIEW with the MODELs
> RESPONSE the user with the VIEW

RESPONSE 就是向浏览器发送页面的意思，而 VIEW 差不多就是页面的意思，MODEL 呢？当然是数据。
数据可以是从数据库里得到的。这里你就看到 Controller 是如何在操纵 View 和 Model 了。

function add
> if METHOD == get
> > RESPONSE with the adding VIEW
> if METHOD == post
> > get todo name from the post params
> > generate a MODEL with the todo name
> > save the MODEL (to mysql)
> > RESPONSE with the success VIEW

add 方法首先判断 METHOD 是 get 还是 post。如果是 get（当你在浏览器里输入一个网址时，就是在 get 该网址），就展示添加页面，这个页面可能是一个表单，几个输入框，一个提交按钮。当用户点击提交时，就是 post 了一个请求。如果 METHOD 是 post，就新建一个 model，存到 mysql，然后向用户返回一个成功页面（success VIEW）

MVC 的流程基本就是这样了。
为什么是 MVC？因为通用。哪个网站没有 Model（数据），除非你是全静态网站；哪个网站没有 View（页面HTML）。而 Controller，是为了解藕，Model 现在只负责数据了，View 只负责页面 HTML，那么其他的脏活累活谁做？Controller。 Router 是来干什么的呢？活太多了，需要多个 Controller 来做，是不是需要一个监工/指挥/经理呢？比如现在这个 Todo 网站允许用户注册了，是不是需要一个 User 类来负责登录、注册呢？Router 就是给他们俩指派任务的人。

我理解的后台 MVC 就是这样了。
晚了，前端的 MVC 下次再讲。

我理解到现在的程度，用了大半年的时间，还是觉得没理解透啊。嘿嘿

你理懂还有段距离吧。 建议你看看李战的《悟透 JS》http://www.cnblogs.com/leadzen/archive/2008/02/25/1073404.html
是他的博客，后来编成书了。第一部分很不错，后面的就差一点。

至于 this 指向哪里，也是不确定的，要看具体环境。
如果你直接运行一个方法，比如
function foo(){
console.log(this) // window
console.log(this === window) // true
}

如果你运行一个 object 的方法，不如

var obj = {
foo : function(){
console.log(this===obj)
}
}
obj.foo() // true

但是你可以使用 call 来指定 this，比如

var obj = {
foo : function(){
console.log(this===myObj)
}
}

var myObj = {}
obj.foo.call(myObj) // true

so...不知道你懂了没。

而写的过程呢，就简单很多了。
this.name = 'hi'
JS 引擎会看 this 有没有 name 这个属性。没有就新建一个 name ，并赋值为1（没有查看__proto__ 的过程）；有就直接赋值。

读 name 的过程和写 name 的过程是不一样的。11楼说的是读的过程。

this 和 prototype 就是 JS 最难理解的两个地方啊。

这是因为 oTest1.setname 中的 this ，指的是 oTest1。所以 oTest1.setname 会在 oTest1（this）上添加 name 属性。



如果你运行 oTest1.setname.call(fTest.prototype,'another name')，那么期间的 this 就是 fTest.prototype 了。
这里涉及的概念是 context。 你可以试着运行下。

this.name 指向哪里，是不确定的。
唯一确定的是 JS 引擎的查找规则。
在你 setname 之前，如果你想读取 oTest1 的 name，那么 JS 引擎首先看 oTest1 自身有么有 name 属性（没有），然后再看 __proto__ 里有没有（有），如果还找不到，它会继续看 __proto__ 的 __proto__。
但是你 setname 之后， oTest1 就有了「自己的」name 属性。你再让 JS 引擎找 oTest1.name 的时候，它依然用刚才的逻辑找 name。
现在应该懂了吧。