Comment by underwater | Hacker News Reader

Comment by underwater | Hacker News Reader

Parent Full thread

I don't know Tim Caswell and whether he's capable of building this probject, but his progress so far sounds pretty unfocused.

  I designed a stream system that's both lightweight and works great in both node.js and browser environments. I spent a day creating a module loader for chrome apps so I could use common.js style modules.

That's after taking almost $20,000 for a Kickstarter campaign in which he detailed the risks:

   But in the case that I'm still wrong and it's way harder than I thought, I can promise that the project will have enough of a head start to survive on its own and be usable before the funds run out.

His repo is open source but there doesn't seem to be any committers apart from Tim. Being able to clone a repo is far from being in a usable state. The actual work that was committed seems to have taken place in a little under two months from April to June.

I get that personal projects can be hard to see through, but Tim is asking for tens of thousands of dollars without explaining how he will approach things differently this time around, or even acknowledging he failed his previous backers.

I'm sorry the progress seems to disorganized. I've recently moved to doing work in the main js-git repo to make things more obvious to people.

As far as the first fund-raiser, I was able to stretch the money farther than I had anticipated but as I mentioned in the second fund-raiser, has a slow start.

It's hard to build a large library like this when basic things like streams, packages, module loading, and binary data are so varied and there are no accepted standard ways to work. This is pioneering work, not paving cowpaths.

Thanks for taking the time to reply. I would be shocked if there wasn't already a Common.js implementation for the browser.

How do backers know that you are going to be able to effectively use the money this time?

What do you mean by common.js implementation? The only thing I know of that survived the common.js movement was that node.js adopted it's module file format. That format requires either sync I/O, XHR loading and wrapping or a build-step or build-server to use in the browser. There are libraries out there that try to solve the module problem in the browser, but there are certainly no clear winners and nothing that doesn't have serious limitations or drawbacks in one way or another.

Also as I mentioned and you quoted, I found a great way to load common.js modules in chrome apps that nobody had done before, but it only really works in that unique environment.

But modules are just the tip of the iceberg. I need a way to handle I/O actions, streams, TCP, fs, db, etc. All these interactions and APIs need to work cross-platform in a variety of different runtimes. I can't even start implementing git clone over a TCP socket till I have a TCP socket API to program against.

But like I said in the bountysource, most of that is all now solved more or less. I have a much better understanding of what needs to be done and I am starting out this phase knowing how git works internally down to even the huffman encoding bits inside the deflate inside the objects inside the packfile stream inside the git clone stream.

I also have more time this round and less conferences that I have committed to speak at or visit. (I think I only have two more trips the rest of the year actually)

Reply on news.ycombinator.com