console.log("func 1");
})();
console.log("in global");
(function() {
console.log("func 2");
亲们，请问执行结果是什么？ 能够解释一下为什么吗？
看源代码：
Node:
NativeModule.wrap = function(script) {
return NativeModule.wrapper[0] + script + NativeModule.wrapper[1];
};
NativeModule.wrapper = [
'(function (exports, require, module, __filename, __dirname) { ',
'\n});'
];
fibjs:
inline result_t _error_checker(result_t hr, const char *file, int line)
{
if (hr < 0 && hr != CALL_E_NOSYNC && hr != CALL_E_NOASYNC && hr != CALL_E_PENDDING)
{
std::string str = file;
char tmp[64];
sprintf(tmp, ":%d ", line);
str.append(tmp);
asyncLog(3, str + getResultMessage(hr));
}
return hr;
}
#define CHECK_ERROR(hr) _error_checker((hr), __FILE__, __LINE__)
CHECK_ERROR(CALL_E_JAVASCRIPT);
说你不懂js，你还真能秀自己多不懂，好好看看《javascript:the good part》。
js不是菜鸟就可以用的。 js不是java、c++，有管家给你写好了各种框子，小朋友也可以持家。 js更像是c、lisp。 我想学c的人都知道看看《c缺陷与陷阱》。
这人是在这推广fibjs的, 你推广fibjs我无话可说, 但是任何一个伟大的人都不会把巨人踩在脚底下来显示自己有多伟大, 顺道说一句, 你以为就你这种素质就能把fibjs推广? 可笑, 低调点吧! 任何语言, 都是一步一步完善起来的, javascript就是脚本语言, 解释执行, require时候检查代码的合法性是要付出计算成本的, 你以为只有你能想到?
@xujun52011 你，说到问题关键点上了。上面某位大牛，跟我争半天，不知道在争什么。计算开销确实是个问题。但如果从减少编码潜在的坑角度来看，还是可取的。而且，计算开销只在系统初始化时增加，应该还算可接受。从node一贯设计哲学来看，有可能真的是出于加快初始化速度考虑，而不做检查。但是这就，留坑给开发者了，这和利用回调追求异步这个大坑一样一样的。关于**js的，我就不多说了，一句话，node挖坑，咱填坑(我们认为的坑)。
我还算是知道node的包引入机制，不算是没研究过。但想到这么用的，你也可以进“不正常人类研究院-nodejs分院”了。不过我突然就在想，下面一段是
(function (exports, require, module, __filename, __dirname) { console.log(“func 2”);
会是怎么回事了。。。
m1.js
console.log("func 1");
})();
var v = "v22222222";
(function() {
console.log("func 2");
m2.js
require("./m1.js");
console.log(v);
执行结果：
func 1
func 2
v22222222
目前发现会造成全局变量污染。总感觉，还有妙用。待研究。
又被转过来了。
使用工具就像谈恋爱，你爱一个人，就连她的缺陷都会觉得可爱。但是客观来说，缺陷就是缺陷。
比如下面这段代码：
var a = 10, b = 20, c = 30;
func1(a, b, c, function() {
func2(a, b, c, function() {
func3(a, b, c, function() {
func4(a, b, c, function() {
func5(a, b, c, function() {
func7(a, b, c, function() {});
});
});
});
});
});
});
func1(a, b, c, function() {
func2(a, b, c, function() {
func3(a, b, c, function() {
func4(a, b, c, function() {
func5(a, b, c, function() {
func6(a, b, c, function() {
func7(a, b, c, function() {});
});
});
});
});
});
function func1(a, b, c, fn) {
fn();
}
function func2(a, b, c, fn) {
fn();
}
function func3(a, b, c, fn) {
fn();
}
function func4(a, b, c, fn) {
fn();
}
function func5(a, b, c, fn) {
fn();
}
function func6(a, b, c, fn) {
fn();
}
function func7(a, b, c, fn) {
fn();
}
在 node 里面会报：
func1(a, b, c, function() {
^
ReferenceError: a is not defined
at /Users/lion/Documents/projects/temp/test.js:16:7
at Module._compile (module.js:439:25)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
在 fibjs 里面会报：
Unexpected token }
at test.js:12:1
你们说说那个会让你的工作效率更高？
@ngot 其实各有优劣吧, 再者说一点, 随便一个ide都能检查出你上面那段不合法的代码的错误, 当然, 你要跟我说notepad, 那我无话可说, 当我没说
ps:最近也在研究fibjs, 可恨c++只懂皮毛, 慢慢学吧.
@xicilion 你这段代码, 一放到ide里面就报错了, notepad++一样, 当然, 我是低端码农, 不会用notepad写代码, 再者, 跟我回复上面某位一样, 如果require需要检查代码的合法性的话, 是要付出运算成本的.
楼主各种黑node.js啊，简单看了下源码，fibjs把gd库，redis，mongodb，mysql等许多第三方软件的驱动都维护到自己的fibjs里的，fibjs整合了大部分web用到的工具，而不必像node.js一个个package的去安装，更像一个整合了好多工具的express，由于很多框架逻辑，工具都是通过c++来编写的，所以性能肯定会好于node.js，但是随着业务代码的深入，这方面优势我想会越来越少。而且有2点，表示对fibjs的前途心存忧虑： 1、这么多工具库，还有fibjs的稳定性，bug测试，新功能开发等等，不知道fibjs研发团队有多少人，能有这么多精力来做这个事情，这是准备累死自己的节奏； 2、node.js的语法已经深入人心，推出一个api相似，但又不尽相同的平台是否明智，如果使用的人不多，没有大项目助威，投资不给力，那问题1就更大了；
＠ngot 的两个帖子（另一个：fibjs比 nodejs 快五倍，本来是孢子论坛fibjs兴趣组的帖子，本来是作者@xicilion 在自己的地盘上为自己的工作分享自己的一些开心，可能被转到这里后产生了一点点踢馆砸场子的感觉？＠ngot 在前一个帖子里面也许言辞激烈了些，这次感觉就平和多了，其实如果有精力，多一个项目大家玩玩不是挺好的么？没有精力的话，简单忽视也就好了，也都大可不必好像非此即彼一样的。看了个帖子能够有点收获，不是也不错？
程序员都有批判的基因，不过了解过后的批判，不是才更有价值和说服力么
换个角度想想，国人CPU靠过谱么？国人OS靠过谱么？国人的普及泛用型编程语言有么？和各种“麒麟OS/kylin”，“易语言”，“狗剩”（这个还在期待。。。)比起来,fibjs至少：
- 有创新
- 不浮躁，不功利，持续活跃
- xicilion发起，无政府背景，不忽悠，不花纳税人的钱
fibjs项目会怎么发展下去那是顺其自然的事，可以观望也可以参与， 不过国人的项目不支持下，然后又各种场合感慨国人不给力，也不好吧。。。
这种代码检查方法都是搞笑的，Douglas Crockford早就在许多年前就发明了类似C Lint的JSLint，想要严格的代码审查，使用JSLint子集。
你对nodejs的这些认识，建立在你对js不认识的基础上，而且我也非常清楚这种js半生不熟的人士非常之多。
我记得有位老外哥们说过一句豪语，“凡是可以用 JavaScript 来写的应用,最终都会用 JavaScript 来写。” 虽然夸张了点，不过也挺有些意味。现在正是一个时代的变迁，java、c++、c#、面向对象的衰落以及scala、f#、函数式对象混合的兴起。
这种想法真是幼稚，除非你想黑一下那种专门留给别人注入代码的菜鸟。 不说js，但就sql就一大堆防止注入的代码准则。 再说js，除非那个菜鸟使用new Function()和eval。
@tulayang 用你的逻辑，回复你一下。用JsLint来检查代码，是搞笑的，因为响马早就研究出了，运行前代码检查。想要，严格的代码检查，请在运行前自动检测。对仗工整，赞一个。什么逻辑～～
你们这些人啊。软件有bug有缺陷是很正常不过的事情。要不然怎么会有contributor的存在呢。
觉得这个就黑了node什么的，实在是玻璃心。node也是在借鉴一些东西的基础上开发出来的，同样fibjs也是。难道有了fibjs之后，写node的人就不能好好的玩耍了么。node开放得早，传播范围广，它的一些设计上的缺陷，可以在后来者中避免。同样，人家找出Node的一处bug（也许压根就不用fix），没必要就吵来吵去的，更应该做的是这样的bug如果能在现在的node中修复，请去官方提issue： https://github.com/joyent/node/issues/new 。在原则性上无法更改的事情，那就包容。
@JacksonTian 非常在理。我转这个过来就是想让大家，换个角度看node.可是很多人，不愿意去思考为什么。第一反应就是：你是谁？ 你凭什么说三道四？ 维护心中偶像的冲动，完全冲昏了本该独立思考头脑。
