

A git implementation in pure JavaScript - nephics
https://github.com/danlucraft/git.js

======
Nitramp
The node.js JavaScript surge reminds me a bit of the early days of Java, where
everyone went to implement whatever existed in C/C++ for Java. Only that this
time people stick a ".js" in the end instead of a "J" in the front.

If history has a lesson, most of this will not be wildly successful, because
the js environment is not suitable for the task to be an actual practical
solution.

~~~
justincormack
Surely if that bit of history says anything then this will be successful?
There is a big incentive for languages to reimplement natively, for Java it
was cross platform consistency and security, for js in the browser it is
complete unavailability of a native code API. (for node.js I am not really
convinced though).

Sure there are some issues with js, eg binary support in browser is painful,
and it is slow, but Java started off slow and lacking features too. It is
improving.

Is now a good time to work on things like this? Why not. Especially if they
feed into language and API improvements.

~~~
Nitramp
_Surely if that bit of history says anything then this will be successful?_

Not sure. Lots of people reimplemented lots of stuff for Java, but it turns
out Java was only successful in the sweet spot for it (networked server side
language); it never replaced C/C++ in any meaningful way.

I expect the same with JavaScript, it will flourish in its niche (in
particular as it has a monopoly as the in-browser-language), but it won't
replace established languages on their respective home turf.

~~~
wisty
It did replace C/C++ in a meaningful way. I think there's probably more Java
jobs out their than C/C++. Though C/C++ is still much better than Java in a
lot of areas, no doubt. You can't write a good looking app, or get write a
kernel.

Maybe "replace" is a bad word though. Java complimented C/C++, creating a
whole new market.

~~~
Nitramp
That's what I mean, Java didn't replace C++, it found its own market. Thus
there is little point in porting everything (for appropriate values of
everything) to Java (or JavaScript); you aren't gonna need it there.

~~~
justincormack
Pretty much everything has been ported to Java. Almost no one programming in
Java uses native libraries at all. I cant think of libraries that were not
ported; the Java ecosystem is now very self comtained relying on innovation
within its own community.

Essentially Java replaced C++ in most of the enterprise programming market.

------
lucraft
OK, I was going to implement write support before posting it up here, but glad
you guys like it.

There's tons more to do :)

~~~
isntitvacant
this looks really cool. i was actually working along the same lines
(<https://github.com/chrisdickinson/tempisfugit>) to get a pure JS git
implementation, though now I'm a little disconcerted since your project looks
so fully featured :) One question: I noticed that you got dakongai's js-
deflate library working with git -- I had tons of problems with getting it to
read deflated git objects (mostly, that it wouldn't deflate them at all), and
I had to turn to jxgcompressor (eventually) to get inflate to work. Before I
saw this, I was planning on shimming in compression support by including a
simple flash-to-js bridge; but if dakongai's library works I'd definitely
rather use it. Again, awesome work!

~~~
lucraft
Nice! Looks like we've done a lot of the same stuff here. Does tempisfugit
require filesystem git repos currently?

Yes, there were a few issues with js-deflate, but once I figured out exactly
what zlib was and what js-deflate does it fell into place. I also had to patch
it to support returning the length of the compressed data read, otherwise
there was no way to know how much of the stream it had consumed.

~~~
isntitvacant
Thanks -- yeah, at the moment it's tightly bound to node's 'fs' module, though
I was planning on abstracting it so you could use 'FileData' in modern
browsers. I've got the three ODB's implemented (and, I think, most of the
types within) -- loose, packv1, and packv2. I've also found that the
jxgcompressor _seems_ to run faster than js-deflate -- you might check that
out.

I was particularly interested in different storage methods for git
repositories in-browser -- like localStorage, or (for fun) writing the git
data to a canvas, extracting it as a PNG, and uploading it to a static file
server which would then send it back as a "cache forever" image; you could
then extract all the data back out of the PNG by writing it to a canvas and
running through the image data. Also fun: writing a backend that relies on
Github's raw object API [1] Or, on the server, running a SQLite backend for
repo data. The possibilities are endless :)

[1]: <http://develop.github.com/p/object.html>

------
dnewcome
I thought about doing an in-browser git implementation for enabling offline
mode in a webapp. Doing things with git would make some really interesting
sync scenarios possible. Looking at what was involved though, I think I'm glad
I didn't go down this particular rabbit-hole.

~~~
cdcarter
Another cool tool in this world is CouchDB. A local instance can replicate
back and forth with a master when available, and you can serve an entire app
right out of the DB.

------
dropkick
FYI, it only does reading but it's still very impressive. I've tried out the
demo and it just works against small repos. It's very slow against larger
ones.

~~~
lucraft
Yeah. I've thought of a few things to do about that. For instance, we could
optimize a repo to have pack files that work well for the browser. [edit] also
there's a load of optimization that can be done on the binary parsing. I
haven't even started that yet.

------
ltw
Yet more evidence of Atwood's Law:

 _Any application that can be written in JavaScript, will eventually be
written in JavaScript._

[http://www.codinghorror.com/blog/2007/07/the-principle-of-
le...](http://www.codinghorror.com/blog/2007/07/the-principle-of-least-
power.html)

~~~
ConstantineXVI
One could consider this[1] as a full realization of Atwood's Law.

[1] <http://bellard.org/jslinux/>

------
tectonic
Awesome, when this can do writing (presumably with an in-memory store for
now), I think there will be some really interesting in-browser version control
uses.

~~~
mmahemoff
Pure client-side wiki with version control, for one.

------
nvictor
what javascript testing library is it using?

------
lurbina
why?

~~~
hvs
I've never understood why this question is asked on _Hacker_ News. Can you
really not imagine why someone would try to do this, even as just an
intellectual exercise?

~~~
tzs
Perhaps he has sufficient imagination to come up with two or three possible
reasons why someone might do this, and hence is asking so as to find out which
is the _actual_ reason.

By asking, he might learn something, especially if the reason turns out to be
one he had not thought of.

~~~
coderdude
You're probably just playing the devil's advocate, but it's plainly obvious
that the guy was just being rude. If he was actually interested in an "I can
see so many reasons you'd make this" kind of way he wouldn't have been so
curt.

~~~
tzs
I don't see that "why?" is curt. It is succinct.

Perhaps in this particular case the questioner WAS trying to be rude, but
that's not relevant to my reply to hvs. Note hvs said he could not understand
why this question is asked on HN. He was talking about people in general who
ask "why", not this particular questioner.

I'm astonished that anyone would be surprised that on HN, of all places, that
people would be curious about why someone is doing something. One of the
defining characters of hackers is curiosity.

