4 ms·

Here's the HN submission from last year: http://news.ycombinator.com/item?id=1261786 http://news.ycombinator.com/item?id=1261786 Not sure how much the product

by mwill 15y ago

Here's the HN submission from last year: http://news.ycombinator.com/item?id=1261786 http://news.ycombinator.com/item?id=1261786 Not sure how much the product has changed since then. Straight off it doesn't use node.js (In the older thread he mentions it's because it's asynchronous thus not simplistic enough), which strikes me as an odd choice (Maybe it made more sense when node.js was younger). I would absolutely use this as often as possible if it used node.js, it would make an awesome jsfiddle for server side code.

olegp 15y ago
I agree about the need to migrate over to Node. Separately from Akshell I'm working on Common Node (http://olegp.github.com/common-node/ http://olegp.github.com/common-node/) which uses node-fibers to implement a number of (synchronous) CommonJS proposals. This now allows for a Rails like, synchronous framework to be built for Node and RingoJS. If it makes sense in the future, I might also port some of the Akshell libraries to run on top of Common Node.
- tlrobinson 15y ago
  I love the idea of node-fibers and Common Node. What are the drawbacks you've run into so far? The Node community seems pretty resistant to alternative concurrency models like fibers, etc, which I think is unfortunate.
  - olegp 15y ago
    From a technical point of view: - no real issues with performance or usage (see benchmarks section in the README, that being said Common Node isn't in production anywhere yet), Common Node runs at about 70% throughput (in req/s) of plain Node and uses around 10% more memory in high throughput benchmarks; comparing Node and CommonJS implementations like for like is difficult though, since for example Node doesn't clear its Buffers - Node's insistence on reserving the "fs" module name & removal of exports.paths has been a slight issue - it means the users either have to set NODE_PATH manually or need to run apps via the bin/common-node wrapper script to retain compatibility with other CommonJS platforms From a community point of view: - as you say, people are pretty resistant & I spend a fair amount of time one on one trying to convince (ex) front end Node.js developers why a sync programming style isn't "magic" and is easier to work with; hoping to remedy that by doing a few talks at various events over the next few months and might write a blog post or two - lack of clear CommonJS proposals for Sockets and Subprocesses - the whole sync ServerJS scene is very fragmented - it would be nice to have a project like commonjs-utils or a subset of narwhal which implemented the JS only modules (like base64 etc.) and became the de facto standard lib that they would all use rather than reinventing the wheel and making it impossible to write portable webapps

by mwill 15y ago

olegp 15y ago

I agree about the need to migrate over to Node. Separately from Akshell I'm working on Common Node (http://olegp.github.com/common-node/ http://olegp.github.com/common-node/) which uses node-fibers to implement a number of (synchronous) CommonJS proposals. This now allows for a Rails like, synchronous framework to be built for Node and RingoJS. If it makes sense in the future, I might also port some of the Akshell libraries to run on top of Common Node.

tlrobinson 15y ago
I love the idea of node-fibers and Common Node. What are the drawbacks you've run into so far? The Node community seems pretty resistant to alternative concurrency models like fibers, etc, which I think is unfortunate.
- olegp 15y ago
  From a technical point of view: - no real issues with performance or usage (see benchmarks section in the README, that being said Common Node isn't in production anywhere yet), Common Node runs at about 70% throughput (in req/s) of plain Node and uses around 10% more memory in high throughput benchmarks; comparing Node and CommonJS implementations like for like is difficult though, since for example Node doesn't clear its Buffers - Node's insistence on reserving the "fs" module name & removal of exports.paths has been a slight issue - it means the users either have to set NODE_PATH manually or need to run apps via the bin/common-node wrapper script to retain compatibility with other CommonJS platforms From a community point of view: - as you say, people are pretty resistant & I spend a fair amount of time one on one trying to convince (ex) front end Node.js developers why a sync programming style isn't "magic" and is easier to work with; hoping to remedy that by doing a few talks at various events over the next few months and might write a blog post or two - lack of clear CommonJS proposals for Sockets and Subprocesses - the whole sync ServerJS scene is very fragmented - it would be nice to have a project like commonjs-utils or a subset of narwhal which implemented the JS only modules (like base64 etc.) and became the de facto standard lib that they would all use rather than reinventing the wheel and making it impossible to write portable webapps