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.
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.
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.
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.
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.
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.
Normally I don't comment on meta issues like downvotes, but as someone who writes attractive Java software, could someone please explain why my comment addressing a common misconception is receiving multiple downvotes?
I also neglected to mention that people are making attractive apps using Java on Android.
However there is great benefit to this young language when a popular utility can be implemented to highlight the weakness of a particular runtime implementation, or even the underlying language.
Git/Hg clients touch network io, file io, and rudimentary hashing in the normal execution path. So it makes for a good subject.
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!
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.
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 :)
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.
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.
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.
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.
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.
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?
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.
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.
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.
I've actually been slowly getting accustomed to this. Before, I used to just drink my hateorade when it came to things like this, but ever since I've started to visit HN more frequently, my tolerance has expanded.
Depends if porting code from one procedural language to another is an "intellectual exercise" (it usually isn't). Compare with the x86 emulator written in JS that we saw a few months back.
That said, viewing a git repo in a web browser by querying the repo over HTTP directly is pretty damn cool.
Because you can. I've made far more useless stuff simply because I felt it would be interesting or a challenge to make. Which in turn are usually the projects I learn the most from.
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.