Nodejs的node-sync库这么好用为啥没什么人用?

Nodejs的node-sync库这么好用为啥没什么人用?

https://github.com/ybogdanov/node-sync

node 的回调太蛋疼了,业务一复杂,再加上错误处理,那代码仅只日狗...,看了不少库,co,promise,yield 感觉都不是很方便.这个库,一下把代码精练了许多,用 fiber 处理应该性能问题不大

// Run in a fiber Sync(function(){

// Function.prototype.sync() interface is same as Function.prototype.call() - first argument is 'this' context
var result = asyncFunction.sync(null, 2, 3);
console.log(result); // 5

// Read file synchronously without blocking whole process? no problem
var source = require(‘fs’).readFile.sync(null, __filename);
console.log(String(source)); // prints the source of this example itself

})

但就是不知道这玩意为啥没什么人用,难道太坑?


29 回复

尽可能不要修改内置类型的 prototype
see https://v2ex.com/t/190956#r_2061759


好东东，有这东东，就不用把函数转成 async function 或者 function()*了。

每个 fiber 会有个栈，如果在复杂应用里广泛使用，估计会死得很难看

如果想用 fib 的话 来这里 http://fibjs.org 孢子社区全站都是用这个写的

尽可能不要修改内置类型的 prototype +1

还是更喜欢 await / async

用 async 顺手了

搞反了吧， co 还不方便😂

因为不喜欢 fiber ，运行时程序流程变复杂了

第三方入侵你的 prototype 是很危险的。

何况有 async/await

用 rxjs

代码不兼容？栈的大小过大？

太多估计会影响性能

这个应该不算修改 protype 吧

es6 已经自带 promise 了 不再需要其他的库

已得 node 恐惧症… 求 node 可视化包管理工具
node 一言不合就开始联网下东西…还下的特别慢慢
和 gradle 有的一比…

下东西难道不是因为你执行了需要连接网络的操作，怪 node 干什么

promise 是无法完全解决回调地狱问题的，而且会传染所有的地方都得用 promise

比 gradle 还是好多了，那货经常下不来

不是啊，明明下载过的东西，比如 ts 项目，它为什么每次都要下一遍 typescript 全部东西…速度还那么慢…就不能用本地的吗？ 问题，到底又没用比较好用可视化管理工具？

有哪个包管理器有增量更新的功能，求告知 😂

增量肯定是没有，不过 npm 3 开始就将依赖扁平化了，大大节省了项目中下载依赖的时间

https://github.com/magicdawn/promise.ify 可破

co 升级到 async/await 指南
- [] Promise.all
- {} https://github.com/magicdawn/promise.obj
- 并发 https://github.com/magicdawn/promise.map
- 超时 https://github.com/magicdawn/promise.timeout
- 重试 https://github.com/magicdawn/promise.retry
- sleep https://github.com/magicdawn/promise.delay

哎~我只是手痒造轮子玩

你可以看看 mongoose 是怎么用的 可 callback 可 promise 解决不了回调地狱是你方式不对

为何还停留在如此落后的回调方式，不直接上 golang ？


Collection.prototype.update = function(selector, document, options, callback) {
var self = this;

// Add ignoreUndfined
if(this.s.options.ignoreUndefined) {
options = shallowClone(options);
options.ignoreUndefined = this.s.options.ignoreUndefined;
}

// Execute using callback
if(typeof callback == ‘function’) return updateDocuments(self, selector, document, options, callback);

// Return a Promise
return new this.s.promiseLibrary(function(resolve, reject) {
updateDocuments(self, selector, document, options, function(err, r) {
if(err) return reject(err);
resolve®;
});
});
}

mongoose 用这种方法解决的,判断 callback 类型,想想这代码写得有多费劲…

https://github.com/digitaldesignlabs/es6-promisify
这个库倒可以稍微简单一点把 callback 接口转换成 promise 接口.


这个…Golang 太灰主流了.没法招人啊

不认为，难道 nodejs 找来的都很牛逼？ golang 招过来 3 天不能贡献代码，此人可开除！

Node-Sync库在Node.js中确实提供了一种独特的同步编程体验，它允许开发者以同步的方式编写代码，从而简化了异步编程的复杂性。然而，尽管它有其优点，但使用并不广泛，原因可能包括以下几点：

  1. Node.js的异步本质：Node.js以其高效的异步IO和事件驱动架构而闻名。许多开发者已经习惯了这种异步编程模式，并认为它是Node.js性能优势的关键。因此，他们可能不愿意引入可能改变这一特性的库。
  2. 项目状态：Node-Sync库在2024年5月30日后已被其所有者归档，意味着不再维护和更新。这对于寻求长期支持和稳定性的项目来说是一个风险因素。
  3. 学习和理解成本：尽管Node-Sync简化了同步调用，但开发者仍然需要理解其背后的Fiber机制和同步调用的局限性。这可能会增加学习和理解的成本。

以下是一个Node-Sync的简单使用示例：

var Sync = require('sync');

function asyncFunction(a, b, callback) {
  process.nextTick(function() {
    callback(null, a + b);
  });
}

Sync(function() {
  var result = asyncFunction.sync(null, 2, 3);
  console.log(result); // 输出: 5
});

总的来说，Node-Sync库虽然提供了一种有趣的同步编程方式，但由于上述原因，它并没有得到广泛采用。

回到顶部