101 JSJ js-git with Tim Caswell

Download MP3



01:34 - js-git


In Two Weeks

Angular & Open Source Projects with Brad Green


AJ:  I have a great disdain for the fact that we live in a society full of fearful impotent men without a drop of confidence. And every real man lighting the way before us is a true champion, face worthy of being put on a box of Wheaties. [This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. Their upcoming course is JavaScript to Node, which covers some advanced JavaScript topics and real-time web development with Node.js. You can also get recordings of their previous courses like JavaScript the Good Parts, AngularJS, CSS3 In-Depth, and Responsive Web Design. Get it all at FrontEndMasters.com.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.] CHUCK:  Hey everybody and welcome to episode 101 of the JavaScript Jabber Show. This week on our panel, we have Aaron Frost. AARON:  Hello. CHUCK:  AJ O’Neal. AJ:  Yo, yo, yo, coming at you live from Provo. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  I’m Charles Max Wood from DevChat.TV. And we have a special guest and that is Tim Caswell. TIM:  Hello. CHUCK:  Welcome back, Tim. TIM:  Thanks. CHUCK:  So, you want to tell us what you’ve been up to lately? TIM:  Yeah. I’ve been missing on the show because I’ve been busy working on JS-Git. And it’s now getting somewhat sort of complete. It’s very exciting. CHUCK:  So, is it oversimplifying it to say that it’s Git implemented in JavaScript? TIM:  Yup. CHUCK:  [Chuckles] TIM:  Although that was what most people thought I was doing. AJ:  That’s what it sounded like from when you said, “I’m implementing Git in JavaScript.” [Laughter] TIM:  I know, right? AARON:  I don’t know how they got that. TIM:  I got to work on my messaging. It’s actually a long-term goal. And the real goal, which I think I explained on the original Kickstarter, is to make programming more accessible, meaning you can program on more devices than you currently can. How do you got to your iPad and checkout your GitHub source code and edit it and test it locally and push back? That workflow just doesn’t exist on many platforms. And one key piece that was missing was if I had Git in JavaScript, I could use Git anywhere. And that was why I started JS-Git. CHUCK:  Yeah, but can’t you install Git on Windows and Linux and Mac? TIM:  Yes, but not all platforms. And on Windows, it’s actually rather painful. CHUCK:  I can see that. TIM:  But Chromebooks. They’re fully functional computers. The high-end ones even have i5 CPUs, yet you can’t install Git on them. There’s no way. You don’t even have a command line. You do if you put them in dev mode and stick Ubuntu in [inaudible], but that’s a lot of work. CHUCK:  So then, how do you use JS-Git? How does it make it easier? TIM:  So, JS-Git the library is a very modular, very open, re-implementation of bits of Git. Right now I have most of Git core. You can create blobs. You can create trees, commits, and annotated tags. There are some helper libraries for walking history linearly because Git history is actually a directed graph, as is Git itself. Git is [not just a] tree. Git is [also a] directed graph. And so, I have code that takes this low-level database essentially and lets you work with it in various ways. And the platform bits of it are modular. So, you can use this in a browser with IndexedDB as your backend, or local storage, or memory. I’m going to write a Web SQL backend so it can run on Safari, because Safari only does for whatever reason. There’s a Node version that can use LevelDB or the file system. There’s a Chrome app version that uses Chrome’s local storage or Chrome’s native file system access, or in Firefox OS there are native APIs, or in Windows apps there are native APIs, and so forth. Every platform has different APIs and different abilities. And I wanted to work on all of them, because that’s my goal, is to have this running everywhere. AARON:  Wow. CHUCK:  So, how much of the work was implementing the Git features and how much of the work was making it work on all those different platforms? TIM:  I’d say at least half of the work was the cross-platform bit. And understanding even what I wanted, how I wanted to organize it. When you’re working in Node, for example, you have npm and you know this. And so, when you want a dependency you add it to your package.json and you npm install it and you’re done, right? Now, let’s just suppose that suddenly you don’t have Node anymore. You don’t have npm. You don’t even have a command line. Now what are you going to do? How are you going to manage your dependencies? But you still want to work with Node because you still want to be in this environment. But you also have to support all these other environments. These are really hard questions. AARON:  Wow. So, can I ask a question real quick? TIM:  Yes. AARON:  We keep on using the word, was it hard? Are you done? How far into this thing are you? Is it usable? TIM:  It’s usable now. AARON:  Wow. TIM:  So, I’ve spent the last two months making a Chrome app that’s an IDE that ties a lot of this together, because my original goal was to make programming more accessible. JS-Git was just a major part of that. AARON:  Wow. TIM:  So, you can go to the Chrome store right now and download the beta version of my app in any machine that has Chrome and it runs great. AARON:  What’s the name of your IDE? TIM:  Right now, the name is just Tedit. AARON:  Okay. CHUCK:  Yeah, I was looking at that. TIM:  I probably should figure out a better name for it. But the reason I don’t say that JS-Git is just re-implementing Git is because that would be easy actually, at least the core parts of Git. And several people have started that. But my intent was more to solve this other problem of making development work on other platforms. Sometimes when you say the JS-Git project, that may encompass all these other things that I did as part of that, whereas the js-git repo itself is just the code that implements the Git semantics. AARON:  So, this Tedit, it’s integrated with Git? I could push to a GitHub repo? TIM:  Yes. At the moment, the pull and push is broken. AARON:  Okay. TIM:  But it does have this other ability where you can live mount a GitHub repo using the REST API. And remember when I said JS-Git’s backend is pluggable? AARON:  Yeah. TIM:  You can use any database as your storage. So, what it does is when you’re mounting a GitHub repo, it uses GitHub as your file system. AARON:  Wow. TIM:  It’s an NFS mount to GitHub. When you create a text file and hit save, that blob is saved directly to GitHub. When you modify a tree, that tree is saved to GitHub. And when you make a new commit, the new commit is saved to GitHub. And then it updates the HEAD ref or whatever branch you’re on. And so, while you’re working, everything’s invisible. None of it can be seen on GitHub. Your history doesn’t change. But as soon as you make a manual commit, it’s all public. It’s instant. You don’t have to push. And I’ve been using that workflow for the last few weeks to develop Tedit using Tedit on a Chromebook, or Windows, or whichever machine I’m on. It really doesn’t matter. This is how I’m able to use Windows without crying. It doesn’t matter. AARON:  So, do you mount a certain branch that you don’t care that there’s a million commits on? What are you doing? TIM:  No, I usually mount master. It doesn’t create a million commits. AARON:  Okay. TIM:  So, are you familiar with Git’s internal structure, the trees and the blobs? AARON:  No. I wish I was. I’m sorry. TIM:  Okay. Let me give you the high-level overview. It’s actually fairly simple. So, Git core, Git internals, not the C library (that stuff’s crazy), but the semantics is you have a blob which is a file or a symlink or basically just data. The hash of it is literally the SHA1 hash of that data plus some header. So, they’re really, really simple. And then a tree represents a folder. And it just contains a listing of this filename points to this hash, this filename points to this hash, this filename points to this hash. And they can point to other trees or they can point to blobs. And then it stores the mode, is it executable, is it a symlink, or whatever. That’s the entire file system abstraction. It’s just trees and blobs. And then there are commit objects. And a commit object points to a tree, has the commit message, who the committer was, who the author as when it was committed, and then optionally the parent commits, because you can have one to ten parents depending on how wide your merge was. So, with this GitHub API I can create blobs and trees directly without ever creating commits. So, I’m treating GitHub like a key-value store. AARON:  When you save a file straight to a Git repo, it doesn’t show up in your Git log history? TIM:  Right, it’s nowhere. AARON:  Okay. TIM:  It’s nowhere in there. And in fact, if you leave it like that, GitHub may eventually garbage collect it, because there are no commits pointing to it anymore. AARON:  Okay. TIM:  I’ll have to verify that. I have yet to hit that issue. Now, in the Tedit app, I do a little more. I have first-class support for submodules. And a submodule in Git is just an entry in that tree, because remember I said the tree could point to trees or blobs? They can also point to commits. And the hash is the hash of the commit in some other repo. And then there’s that special .gitmodules file that tells you where that other repo is. And I added first-class support for that in Tedit. So, you can mount and rename and move and copy submodules just like they were local folders. And that’s how I do my dependency management, because I don’t have npm in this environment. And in order to track those, I have to create temporary commits anytime I change content. But these temporary commits don’t create history, because I just set their parent to the old parent. They don’t remember each other. And then when the user makes a real manual commit, I just squash all the temporary commits and they’re gone. Your project’s public history, you see nothing until you manually commit. And then that’s all you see. So, even though there are perhaps hundreds of temporary commits, they’re completely invisible and they’re garbage collected by the backend, whatever that may be. AARON:  Wow. CHUCK:  So, what if you’re hosting you repository somewhere other than GitHub where you don’t have the REST API? TIM:  Then, that’s why you need to wait for me to finish Tedit. [Laughter] TIM:  I have a task for that. And I was making good progress on it. And then I had to take a break and do some consulting work. CHUCK:  Very nice. AARON:  So, it sounds like you’re focusing on the browser first. Is Node going to be secondary or are you done with the Node piece? What’s up with that? TIM:  So, JS-Git itself, I think there are four generations of the code where I write things and then throw it all away and then write things. And there were past generations that were working in Node. In fact, one of the repos in my GitHub is jsgit (without a dash). And that is a Node command line tool using one of the old versions of JS-Git that lets you clone and walk the history and a few read-only things. And I fully plan to support Node. Right now, a lot of my websites on creationix.com are actually hosted using JS-Git. I have this project I’m working on that lets you take a GitHub repository and mount it using the same mounting technology and then server it from that mount directly. So, it’s like GitHub pages, like GitHub.io except it has the same build system as Tedit, the same build rules. AARON:  That’s interesting, man. TIM:  I plan to support Node. There are a lot of people who want to use it. I just haven’t focused on it because if you have Node, I assume you have a command line and you have access to real Git already. AARON:  Right, right. TIM:  So, I can’t think of a use case where you’d have Node but no way to use Git. AARON:  Yeah, that’s true. CHUCK:  So, you built this in order to support more people being able to do programming. And my understanding is that you’re opening this up so that you can teach kids to program in the programming language you created called Jack. TIM:  Right. That’s a future plan. I’ve been working on language research for years. I worked on CoffeeScript way back before it was popular. I had an old language called Jack back then. I delved into Lua pretty deeply. I ported all of Node to Lua just for fun. That took about a year. And Lua was close to what I wanted. I want something that’s simple, that doesn’t have a lot of exceptions to the rules, but has a similar semantic to JavaScript. There’s a lot I like about JavaScript. It’s very flexible. It’s very powerful. But as every JavaScript developer knows, there are a lot of gotchas in there that are just really weird and really confusing to newbies who are learning to program. Jack language is essentially a simplified version of JavaScript with a little bit of the goodies from Lua mixed in. CHUCK:  Interesting. So, I’m a little curious. How long do you think it’s going to take you to reach your vision of this? TIM:  I don’t know. It’s getting close. The Tedit app right now is functional. I’ve been using it for my main development for several weeks. It’s by no means user-friendly or something that kids would like to just pick up. But most of that’s just UX stuff. It just needs some polish in the interface. The workflow I created with the submodules and the build system and the hosting platform that goes along with it is actually pretty complete. And people could use it to write Chrome apps or web apps really well, really easily, and just with JavaScript, not with Jack. CHUCK:  Does it just execute within whatever HTML context it’s running in? TIM:  No. So, Chrome apps have this security sandbox where you can’t eval code. CHUCK:  Okay. TIM:  Because you have privileged APIs. They don’t want to combine privileged APIs with eval. CHUCK:  Right. TIM:  It’s a bad combo. AARON:  Yeah. TIM:  But what they do allow is inline workers where you create a string, turn that into a blob, and then from that blob make a web worker. And that sort of gives you eval but it’s in a sandbox actually running on a separate thread, completely asynchronous. And so, Tedit has this declarative build system built-in on top of JS-Git, on top of the JS-Git file system abstraction. So, JS-Git is your file system. You’re not editing files on disk. You’re not editing files even in sandbox. You’re editing files in the Git directly. And there are these build rules which, for example, I have this web app exploder.creationix.com. And if you go there, it’s just a client-side app that uses touch events to move a bunch of stuff around when using WebGL. But the app works offline. And the reason it works offline is because I have an app cache manifest. Now, anyone who’s worked with app cache manifest knows they are a royal pain in the rear. AARON:  Yup. TIM:  Have you guys worked with them? They’re really painful. JOE:  Yeah. AJ:  They’re horrible. The worst part is when you can’t update it, because you can’t update it. TIM:  Exactly. AARON:  Yeah. TIM:  Exactly. AARON:  I’m excited for the service worker API coming out. TIM:  Oh, as am I. I can do some really interesting things with that with JS-Git. But it’s not there and it’s a long ways off. AARON:  Yeah. TIM:  So, we have app cache for now. So, what AJ pointed out is the update part. And that is the biggest pain for me. Even when the browser’s behaving and there are no weird quirks, you still have to update your app cache every single time you change anything else or the browser will simple never even check. It’s a feature. It’s a design. So, using Tedit’s build system, you can make a dynamic app cache file that renders itself using an app cache filter. And what this will do is it will take a list of files. It will then read all those files using Tedit’s build system recursively which generates an e-tag for each file. And then I pin those e-tags as comments in the app cache. And so, the end result is I’m in the editor, I edit my JavaScript file, save, go over to my browser and hit refresh, and it will dynamically render a new app cache with new e-tags which makes the browser refresh. And everything works great. The holy grail of development is you edit your code, flip over, hit refresh, and you see your changes. And with this dynamic on-demand build system, declarative builds system, I’m able to do that. There’s no command line. You don’t have to go down and say grunt or gulp or whatever, run this. It’s all automatic. You just declare your rules and how to create the dynamic files, and they’re all created dynamically in these safe sandboxes. The hosting platform that goes along with it has the exact same capabilities. AARON:  So, how have you found using these multiple threads on Chrome apps? Has that been performant or do you have any issues with the web worker stuff? Or is that all working well? TIM:  I never had many performance issues to begin with. I’m sure it probably helps a little in the UI responsiveness. As far as problems, I’ve just hit a few. Generally all this stuff is very cutting edge. I found many bugs in GitHub’s API. I found several bugs in Chrome. I crash my Chrome a lot more often than I would like. AARON:  [Chuckles] TIM:  But the people at Google are always very interested in, “How did you crash Chrome? Give us a bug report.” They take that seriously. And the web workers, I have these intermittent issues where it’ll say the data that I’m trying to post across the channel is not valid, that it can’t be serialized. But a minute ago, it was fine. And I haven’t seen that lately, so maybe they fixed that bug. Other than bugs, I haven’t had any issues with it. It’s just a lot of these are new APIs that haven’t been tested as well. AARON:  Right, right, right. That’s interesting, man. I was interested in a little bit more background on this project, if it’s okay. Have you guys talked about this on an earlier show? Have you guys talked to Tim about JS-Git on an earlier show or is this the first time? CHUCK:  This is the first time. AARON:  How was your Kickstarter experience? Was that cool? How was that experience in getting this thing going off and going and what kind of support did you get from the community, moral and otherwise? How was that? Was that pretty cool? TIM:  That’s a great question. So, about a year ago I decided that I wanted to really make this JS-Git thing but I was too busy doing consulting fulltime, or contract work. I couldn’t really do it, because it’s a huge project. So, I heard of Kickstarter and created a Kickstarter. And within 12 hours, I’d hit my goal. AARON:  Wow. TIM:  Which taught me two things: one, people thought this was a cool idea, and two, my goal was way too low. AARON:  Yeah, totally, right? CHUCK:  [Laughs] AARON:  As a matter of fact, when I saw your goal, I was like, “Dude, this guy is smoking. It’s going to take way longer than that.” TIM:  [Laughs] You were right. So, with Kickstarter, what’s your minimum goal? Because if you don’t reach this, you don’t get money. CHUCK:  Right. TIM:  And I took that literally. Well, my minimum goal, I thought about, okay what would make it worth my time to fire all my clients and work on this fulltime? How much will the absolute minimum time I would need to make this even worth it? And so, I figured that out and it was a fairly small number. But that was the minimum. That was just to get started, not to re-implement all of Git. That would be insane. Nobody is that fast. AARON:  Yeah, I know. TIM:  And so, I post this minimum goal and everyone just assumes, “Oh, this is all the money he needs? Fabulous. Let’s fund it and we’re done.” And as soon as it hit the goal, it just slowed down to a crawl. AARON:  Oh, man. TIM:  So, if you ever do a Kickstarter, unless it’s just hugely popular or you have really good goodies to give people, you’re not going to go much past your goal, because people are going to assume the goal is all you need. AARON:  That’s interesting. TIM:  I really wish they had tiers or something built in where I’d say, no, I really need this, if you want. And I even added stretch goals. And it helped a little. But I had no idea how long it was going to take to develop these things. I knew it was going to be more than a couple of months. But that’s really hard to estimate. No one’s really done this before, because I also had to solve all these cross-platform issues as well. AARON:  Yeah. TIM:  I was going to say, did you want me to talk about the second fundraiser as well? CHUCK:  Yeah, go ahead. AARON:  I didn’t even know about it. Go ahead. CHUCK:  It’s on Bountysource, right? TIM:  Yeah. It was on Bountysource. So, the Kickstarter money eventually ran out. It obviously didn’t last that long. But I did make it stretch, what was it, six months? It was stretching. And then they came to me. They said, “We’re like Kickstarter, but we want to support open source projects in particular.” And they said they would handle the stickers. They would handle the t-shirts, because at Bountysource I had to order my own stickers, do all the [inaudible]. And that alone was hundreds and hundreds of dollars and lots of time just to print and ship all the backer rewards. And Bountysource, well they came to me and said, “We’ll handle all that for you. We’ll just take a cut off the top to pay for it.” AARON:  Wow. TIM:  And so, I made another fundraiser on Bountysource with a more realistic goal. And that fundraiser started out really slow. It was terrible. I think I was several weeks in and nowhere near the goal. AJ:  Wasn’t it 12 hours left and then Mozilla donated 78% of what you needed? TIM:  Yeah, Mozilla saved me on that one. [Chuckles] TIM:  Pretty much. Mozilla’s awesome. They were also the largest donator in the first one. Basically, if you’re doing something cool with JavaScript, Mozilla likes that. AARON:  Wow. TIM:  Because they’re non-profit and they want to support the web. So, they have very different priorities. AARON:  Why do you think the second one was less funded? Do you think it was because the site’s just not as well-known as Kickstarter? What do you think the deal was? TIM:  That may be part of it. I don’t know. I expected a lot of the people to come from my personal network. But my personal network, I’ve learned, is not actually that large. It feels to me that a lot of people know me. But no, that’s actually not the truth at all. That’s just the way it feels in our self-selected social networks. AARON:  [Chuckles] TIM:  There are a lot of reasons. I actually went to several conferences and talked to companies and asked them why they’re not donating. I was sure that Google and GitHub would give me a ton of money, because well, this makes their products better. And in the end neither one donated anything. AARON:  Wow. AJ:  Yeah, that’s really strange. TIM:  I know why and it’s interesting, but just different priorities, different ways to do business. But the Bountysource, it was eye-opening to see how much slower the second fundraiser was. I think part of it was because a lot of the people who knew me and funded the first one were questioning why I needed more money, because they had assumed that was all the money I needed. And they were less inclined to fund again when I’m just asking for more. And part of it, like you say, maybe because Bountysource is less well-known than Kickstarter. Maybe they’re not as trusted. I don’t know. I’m sure there are a lot of reasons. AARON:  But you did meet your goal? TIM:  Yeah. Mozilla saved me and so I was able to work on it fulltime for another few months. Around New Year’s, the money started really getting low. And so, that’s when I pivoted and started working on this Tedit product with hopes of maybe selling Tedit. Of course, the day I was going to launch the beta for Tedit, GitHub announced their editor and blew that out of the water. AARON:  [Chuckles] Yay. TIM:  Not that I blame them. They were working on that for six years. [Laughter] TIM:  It’s been a long time coming. AARON:  Yeah, it’s exciting. AJ:  Wait, I actually feel really stupid. I’m not aware of this GitHub editor. TIM:  You missed all that? The Atom.io editor. JOE:  I know all about it, but I’m going to let Tim explain it, because I totally know everything about it but I’m just going to let Tim explain it. AJ:  Okay. AARON:  [Chuckles] TIM:  Yeah. I don’t have a whole lot to say about Atom. It’s a CoffeeScript thing, like brackets, written by GitHub people that lots of people are interested in. It looks like Sublime. It’s a native app and only runs on Mac which means I can’t use it. JOE:  And it’s got Node.js integration. I’m glad to see that they’re focusing on what matters. CHUCK:  [Laughs] TIM:  Yeah. I would love it if they would release the core, because they have something like node-webkit but not. It’s Node plus Chromium. JOE:  Oh, wow. TIM:  I would love it if they released that. Atom.io is half open source and close licensed. JOE:  Oh, that’s interesting. AARON:  Wow. TIM:  And from what I hear, it’s not going to be free after the beta either. But, whatever. AARON:  I have some invites. If anyone needs an invite, I have a couple of invites. TIM:  [Laughs] That’ll go fast if you tell people. AARON:  Yeah. I have a couple. CHUCK:  How do they beg you? AARON:  I’m js_dev on Twitter. But I’m guessing that you guys will take my invites before the listeners ever get a chance to. [Laughter] JOE:  Yeah, I want an invite, Aaron. AARON:  There you go. I’ve already got three people who want this. TIM:  Alright, they’re gone. AARON:  Yeah. [Chuckles] CHUCK:  Yeah, but when we sign up, we’ll have invites. AARON:  True. JOE:  Oh, okay. Well, there you go. That makes sense. CHUCK:  If you tweet @JSJabber, the guys on the show will keep an eye out for it. TIM:  Somebody might have one. AARON:  Yeah. TIM:  I have no hard feelings against GitHub. It just really ruined my marketing timing. And plus, Tedit’s not quite ready either. AARON:  So, as you’ve been talking I’ve been thinking. It sounds like this JS-Git, when people start using it and write some tools around it, and correct me if I’m wrong, you thought way more about it. That’s why I’m going to ask you, because your head’s been in this for a long time. It sounds like you could build some tools to be a competitor with npm or something. What kind of stuff do you think you could do that would give npm a run for its money? What do you think about that? TIM:  So, what I have right now in Tedit, since I can’t use npm, I had to build an alternative. And what I have currently is I just use submodules. But as most everyone who uses Git submodules knows, they have some serious issues in usability. And I believe those can be fixed. Most of them are just UI issues in the Git client. When you add a Git submodule, it does not record the branch or tag you added that from. Because remember, a submodules is just a tree-in-tree whose type is commit and whose hash is the hash of the commit in this other repo. So, the only context you have is the hash to the commit. And the commit itself will know who its parents are. So, you can get history, but you have no idea how you got there. And in the .gitmodules file, all they store is the URL to the repo. They don’t store what branch or anything. So, the first thing I’m doing is I’m adding to the .gitmodules file format to store what ref you were in, whether you were in the master branch or you were on some tag. And that’s going to be the replacement for your package.json. Instead of declaring your dependencies there, you’ll declare them in your, or you could, I haven’t figured out the UI for this, you could declare them in your .gitmodules file. And I could even make Tedit or whatever you’re using smart enough to where you could put a range of tags in the ref, like a semver range, like tilde version 0.1.4.  And it would fetch all the tags from your Git repository, find the one that matches, and then update your local commit to point to that. So, you can have auto-updating Git submodules that knew what to update to without breaking the API, or all those nice things you want. And the other nice benefit you get of this over what npm has is previously in npm, you could force publish, which would mean even if someone was depending on a specific version, the author could do a force publish and break your code. And so, it was very unstable to depend on npm for production. Isaac’s since disabled that because of that. But with Git submodules, you point to a hash. The hash is the hash of the content of the commit. And nothing can change without the hash changing. AARON:  Yeah, no questions. AJ:  Yeah. AARON:  It’s awesome. TIM:  So, you’re guaranteed unless you update your submodule yourself, you’re never going to get new content, which is part of the pain of Git submodules, but also the benefit. And so, if I add this other UI that gives you a way to just say, “Hey, update submodules,” and it smartly updates then and maybe shows you a diff of what’s updated, that could be really handy. And the backend, instead of a central repository, it’s just Git. And once I get push and pull working again, it can be any Git repository. AARON:  So, the way that npm allows us to configure all this is they give our package.json. It sounds like you’ve done some replacement of npm for your own purposes, just because in the browser you don’t have it. What format, what’s the manifest to talk to this system you’ve built? Is it JSON or do you have another format for that? TIM:  So, currently it’s just the Git modules file, which is, the format’s defined by Git. It’s basically INI. It’s really simple to write. AARON:  Okay. TIM:  I’m considering something like a package.json where the tool writes the .gitmodules file for you, maybe for compatibility with existing things or just familiarity for people. The only file format I’ve invented I call the Jon format. It’s a subset of the Jack language. It’s Jon object notation. And interestingly, the John format is a strict superset of the JSON format. It’s basically JSON with comments. And you don’t need to quote your keys and you don’t have to put commas at the end of your line and stuff like that. AARON:  Gotcha. TIM:  So, all the build rules in Tedit are written in Jon format. And if you don’t know Jon, you can just write JSON and you’re fine. But as far as the package dependencies, I’m still just using normal vanilla Git submodules with a little extra metadata just mixed in that same file. AARON:  So, are you considering allowing people to alias Git repos like npm has? So, they built npmjs.org where you register your Git repo as a Node module. Are you thinking about building gitjsmodules.org or whatever, where it would allow abbreviated names onto whatever your package.json replacement is? TIM:  I have not considered it. No. AARON:  Okay. TIM:  Just a central namespace like npm gives you but still pointing to these distributed backends? AARON:  Yeah, something like that was what I was thinking. TIM:  I haven’t really felt the need for that yet. When I’m coding, I don’t add dependencies that often, maybe ten in a day. And I don’t mind typing ten full URLs in one day of work. AARON:  Okay. TIM:  It’s not a bottleneck for me. So, if it is for someone else then I can consider something. AARON:  No, I’m just totally intrigued by all the green pasture that you’re looking at and all the stuff you’re doing. This is pretty cool. TIM:  Oh yeah. It’s total greenfield which means you get lost and you find bugs and all sorts of interesting things. AARON:  Yeah. TIM:  The other use that I use JS-Git for that I want to use it for is as a database for normal client-side apps, not using it for code storage. One example I have is, this is actually what I experimented with a while back, the [inaudible] church has a catalog of all of their content, the scriptures and their conference talks and everything. And it’s online via this REST format for their mobile apps to consume. And one day I wrote a script that takes all of that and converts it into a Git repo where I had a branch for every module. So, there’d be a branch for this book, or a branch for whatever was downloadable. Because in their original format you had these downloadable modules that you could download to your mobile phone so that you could view them offline. And with Git using the Git pack protocol, the push and pull protocol, you have to grab everything unless they’re in separate branches. So, you can’t clone a folder in Git but you can clone just a branch. So, the experiment was I took all this data and converted them into Git branches. And I was going to make a mobile app which would have JS-Git embedded and just download whatever branches the user wanted. When the publisher wanted to produce new content, they would just push to a Git repo. And then all the browsers or mobile apps or whatever would just check the remotes and see if the HEAD has moved. And if it has, just download the new content through the pack protocol. And it would be a really efficient way to synchronize published data across many, many clients. AARON:  That’s crazy, man. That’s awesome. TIM:  You don’t have to use Git for code storage. It’s a database. You can use it for anything. It certainly has its constraints. You don’t want it for anything that has a high rate of change. Please don’t use it for a pub/sub mechanism. That’d be terrible, because Git is immutable. You just create new objects that replace the old ones that point to the new ones. You don’t want a high rate of change with that. The garbage collector will hate you. AARON:  That is very cool. AJ:  Yeah, I got to say Tim, that you have all these crazy ideas. Obviously you just love Git and you just have these amazing ideas about how to manipulate and use Git and do things with it that I just can’t believe somebody ever thought of these things. TIM:  [Chuckles] I don’t know if I exactly love Git. But it works for what I’m doing. I’m just trying to find ways to use this thing I’m making. AJ:  [Chuckles] TIM:  I very much am guilty of, “You’ve made the technology. Now let’s find a use for it.” AJ:  Where do you see JS-Git and Tedit going in the future? TIM:  So, JS-Git for sure is an open source project. It will always be. And it just needs polish right now. The last couple of weeks, I’ve been working on unit tests and documentation to document what’s there now. I pretty much finished the first two milestones. There were four. The second milestone isn’t quite done. The last missing bit is push, which I have almost working. I just, my time got cut back a lot recently. So, that would just be a modular system. As people use it, it’ll just be a community open source project where people can take it and use it wherever they want. Tedit, I’m still unsure about. I would love to just give away everything I make for free. In my ideal world, this is how it would work: I would make things that are valuable, and the people who find them valuable would give me money, and then repeat. AJ:  Yes. TIM:  And then there’s the real world. That doesn’t work. So, I don’t know. If I can find enough consulting work then I’ll just give away Tedit, because I really don’t want to charge for it. I don’t want negated, that goes against my entire goal of making it accessible, because I grew up poor and I never would have been able to pay even $10 for something like that. And so, once I put a price tag on it, all these people who are like little me wouldn’t be able to use it. Plus I want it open source. And it’s hard to charge for something that’s open source. That’s interesting, too. Especially if it’s really open like MIT where someone can legally take your code, put their name on it, and charge for it. Or give it away for free in the same Chrome app store. That’s perfectly legal. AARON:  Yeah. TIM:  Why would someone buy my version when there’s a free version of the exact same code? AJ:  I think that sometimes you want to give people something for what they did because you find it useful to you. Obviously the number of people that pay go down. But the philosophical question of why would you pay for something that’s available for free is because you recognize the value and you want to attribute. TIM:  Yeah, you’re right. Well, I had the exact same issue crowdfunding. I would go to these various companies and I would say, “Hey look. I’m making this JS-Git thing. But I need funding to finish making it. Your company would benefit from this. Would you like to donate to it as part of your company?” And they would be like, “Wait. So, let me get this clear. So, you’re saying my competitors can use this for free if I pay for it? And if I don’t pay for it, you’re going to do it anyway?” And suddenly they weren’t interested. CHUCK:  [Laughs] AJ:  Yeah, I guess it depends on who you’re talking to. That’s weird though, because if you’re talking about Google, they give away everything for free anyway, all their stuff. The only thing they haven’t open-sourced that is a really useful tool is their search engine and then the thing that they’re using to scrape websites to do the web searching. Because we have Phantom. I don’t know why Google doesn’t let us use their tool, because obviously they’ve got something that’s way better than Phantom. But, meh. TIM:  [Chuckles] Yeah, I’ll stay away from that comment. [Chuckles] TIM:  Free is not always free. [Laughter] TIM:  But no, I talked to Google and they were very nice to me. They’re like, “We just don’t fund that kind of project.” It’s just not something they do. If it was used heavily internally or if it was something Google employees were doing, that would be different. But they don’t believe in funding every open source project out there. Like every business, you have to justify money you spend. Even honest business owners who want to be generous, if they go to their shareholders and say, “Look, I want to donate to this project,” but it’s not in their business’ best interest, they’re not going to be able to. So, it’s tricky finding the balance between people’s good will and providing for yourself. one of the things I found most interesting working on JS-Git is over the months I would tweet or announce about my progress. And half the replies were like, “I don’t really care so much about your technology. But would you please write a book about how to be self-funded?” CHUCK:  [Laughs] TIM:  “Would you please tell me how to work on your passion and make money?” People are very, very interested in that. JOE:  Right. TIM:  And most of the people that follow me on JS-Git are following me because they think it’s cool that I’m trying to bootstrap and make this open source thing. They also think that JS-Git is cool and interesting and weird. But more, they’re interested in how can I do the same thing? And that’s a problem I have not solved yet, because I myself am barely making ends meet. So, obviously it doesn’t work. But it sure was fun. AJ:  Yeah, we need to find the path to riches so that we can concentrate on what’s important. [Chuckles] TIM:  Yeah, I don’t know if you guys talked about it last time, but Isaac has some very interesting ideas along those lines. He has a post on Medium about why current money in open source is wrong. It’s a very interesting read. CHUCK:  Can you put a link in so we can put it in the show notes? TIM:  Yeah, I’ll find that link. AARON:  So, eventually I think the endgame here, and correct me if I’m wrong, I’m not trying to assume anything, is that grunt builds and gulp builds and our Chrome apps and whatever platform we’re on uses Tim’s JS-Git implementation. And there’s a myriad of tools built on top of that. Does this replace npm? That’s a serious question. I’m not sure what to say. Does it replace npm? Is this that big? TIM:  It could. Technically, there’s no reason it couldn’t. Now, we all know that technical doesn’t mean anything in markets. And npm has a tremendous amount of value. It has a huge community. It has a huge amount of data in it and a lot of people who love it. And I’m not even going to try to compete with that. I’m just trying to make something that works in a wider variety of cases and works for me. But technically, I’ve been working on Node modules recently using Tedit which is a little wonky, but you can do it. And while you still need Node installed on your machine to run the code, you don’t need npm on your local machine. You can just use Tedit for everything else. It’s very interesting, which of course means no native modules, because there’s no compiler in Chrome for that. That would be crazy. AARON:  So, you use Tedit and the JS-Git stuff to pull down the Node modules. And then that way you don’t have to do npm install? TIM:  Right. AARON:  And then you can run your Node stuff? TIM:  Right. If you go to js-git on GitHub, you’ll notice that in my package.json all the dependencies are Git URLs. So that, even if you npm install js-git, you’re going to use Git URLs for all of its dependencies. And in fact, I don’t think I’ve published any of that to npm in a while. I’ve just been too busy trying to get this other stuff working. So, the version of js-git on npm is actually quite old. But if you want the current code, you just npm install from the Git URL instead of the js-git name in the npm registry, because npm works fine with Git URLs. You just need a package.json with the right formatted dependencies. AARON:  That’s very cool. CHUCK:  So, when you’re famous, you’ll remember us, right? TIM:  [Laughs] When I’m famous. Right. CHUCK:  Good, just checking. AJ:  You’re famous in my heart, Tim. AARON:  Yeah. Timmy C’s already famous for us, man. TIM:  Awesome. You guys are nice. CHUCK:  I meant world-famous, not JavaScript-famous. [Chuckles] AARON:  You meant when JS-Git solves the impending zombie apocalypse, right? CHUCK:  That’s right. AARON:  Yeah, okay. TIM:  Right, that zombie module that, right, yeah. AARON:  Yeah. TIM:  Got to kill the zombie processes. AARON:  Yeah. AJ:  Actually, I’m pretty sure Rebecca Black already did that. [Laughter] CHUCK:  She did it on Friday, Friday. TIM:  Okay. On Friday. AARON:  That’s funny. CHUCK:  Alright, do we have any other questions or should we do the picks? TIM:  I think I’m good. Anyone else? AARON:  Yeah, I’m good. CHUCK:  Alright. Well, if they have any other questions or they want to check up on this, what’s the best way to do that? TIM:  There’s a js-git repo on GitHub, js-git. There’s the Tedit repo. They’re both under creationix. Or just send me an email,  HYPERLINK "mailto:tim@creationix.com" tim@creationix.com. Or when Twitter’s not broken, you can ping me on Twitter. I’m @creationix. CHUCK:  Gotcha. Alright, Joe, what are your picks? JOE:  First I’m going to pick the book, ‘The Power of Habit’. I was on a long drive over the weekend on vacation. I needed something to listen to. And so, I was listening to ‘The Power of Habit’, which I’ve listened to before. And it was just such a really interesting book. I’ve really just enjoyed listening to it the second time again. It’s been a couple of years since I listened to it the first time, or a year. Anyway, I really enjoyed it. So, it’s all about personal habits and organizational habits, and how to change your habits, and how to create new habits, and how to identify bad habits. And it’s a really interesting book, both for a personal perspective and for your organization. I also want to pick a game. It just came out today in its early access on Steam. And it’s called ‘Frozen Endzone’. And it’s basically a sport game like football. But it’s a tactical game, like a turn-based tactical game based on football. And it’s done by the people who did ‘Frozen Synapse’, so really awesome-looking game. I haven’t actually played it yet. But it looks really cool. The Penny Arcade guys are talking it up. So, I’m going to pick that game. And then my last pick’s going to be the conference That Conference, which I picked last year, which is a conference held in Wisconsin at a huge indoor waterpark. It’s a technology-agnostic conference. Talks are about anything. So, JavaScript talks, cloud-based talks, all kinds of stuff, mobile. And it’s a really fun environment, really fun place to go hang out. They do a lot of bacon. And that in my book makes it a winning conference no matter what they’re talking about. So, those are my picks. CHUCK:  Awesome. AJ, what are your picks? AJ:  Alright. So, since we mentioned the zombie apocalypse, I have to pick a YouTube video that was put together by a bunch of 12 and 15-year-olds called Doomsday which is a parody of Friday. And they definitely demonstrate that we’ve got that under control. And let’s see. What else? So, Stripe. Stripe is freaking awesome. And this is the reason why: because Stripe puts money in your bank account, which is what we all want as developers. But, here are some sweet things they do that I think everyone needs to pay attention to and copy. On their developer documentation, they have an API key and an API secret that are a working API key and secret that everything that you do with them works just as if you were doing it for real. So, except obviously you don’t get money in your bank account from it. But, you can just copy and paste their documentation and within five minutes be using their tools. And I think that’s really awesome. It’s just mind-blowing to me that they’ve done the one obvious thing that no one else is doing with all of their APIs. You have to register and you have to sign up. So, there’s this barrier to entry. And they’re working with payment processing. So, it’s totally worth the barrier to entry to figure that stuff out. But they have taken just one part of this process that lots of us have been ignoring and made it simple. They gave you the API key and the API secret and the tokens and all that stuff in the example documentation. So, you can build your stuff out, you can get it working, and then you can just swap it out with your keys. And pray that you don’t forget to swap it out with your keys so that the money actually goes into your bank account. Also, I’ll pick PouchDB. CouchDB is what I’m picking there. I think it’s awesome that CouchDB defined a targetable API that other databases are implementing in different ways. It’s like CouchDB succeeded where SQL failed in terms of creating a standard that people can follow. And that you can find modules that fairly reliably replicate that API and get the same results, whichever one you’re using. So, there’s CouchDB, PouchDB, TouchDB. There may be a few others that aren’t quite as well-known. I just really like that that happened. That’s cool. And then lastly, I will have a little self-pick. I was having some trouble because I made my own OAuth service and I also made my own OAuth client. And because I was cheap and I only paid $20 for the SSL certificate, it’s four, five levels down the chain and it has certificates that aren’t well-known. And so, in order to be able to have the client connect without disabling SSL which is what all of the Stack Overflow posts were telling people to do, I didn’t want to have to disable SSL in order to get it working with these cheap certificates, and there’s no way to add certificates in Node. You can only replace the existing certificates with the one you specify. So, I got on the mailing list. And it turns out that just a couple of weeks ago, somebody had figured out how to parse the Mozilla certificates. And so, he just linked me to his gist and then I tweaked it just a touch and wrapped it all together in a module on npm. And so, if you are thinking about disabling SSL certificate checking because you’re getting all sorts of errors because you have to include custom certificates, don’t do that. Use ssl-root-cas and enjoy encryption and also knowing that the encryption is serving its intended purpose, i.e. it’s verified. CHUCK:  Cool. Aaron, what are your picks? AARON:  I got two picks this week. I think it was announced toward the end of last week. And it’s Project Tango. It’s a project from Google. It’s a new type of phone that allows for some really accurate 3D modeling of the world around you. And they’ve got some pretty ambitious goals. It’s super alpha at this point. But I’m excited to see what it can do and see what they’ve done with Kinect-like multi-sensor scanning to get some 3D modeling going. So, I’m going to pick Project Tango. And then I’m going to pick Jake Weary. And I mean Jake Weary, not jQuery. In preparing a talk about JavaScript that we’ll be giving tomorrow at Fluent, I found this music video by this kid named Jake, Jacob Weary. And I couldn’t stop laughing. It’s going to be the new Rickroll. I’m convinced. And so, I’ll throw it into the thing. But everyone needs to go like it and comment on it, because it had me dying. So, those are my two picks, Jake Weary and Tango. CHUCK:  Awesome. Tim, what are your picks? TIM:  Alright. So, we were talking before the show about my desktop and I think it’s a pretty cool desktop. It’s the ASUS Transformer all in one whatever. It’s a 19-inch Android tablet with a full desktop CPU as well. And you can separate the two. And it really helps for testing Tedit because I can just pull off the top and go to Android mode and test the web version of Tedit in an Android environment. And it actually works pretty well there. And then pop it back on and switch to Windows or Linux or whatever. And so, I have one machine that can do almost all my testing. And also, when I’m coding, I like listening to Pandora to sometimes drown out the noise, because I work from home and my kids are homeschooled. So, we’re always home together. And Caravan Palace is one of my fun stations on Pandora. They are electric swing. So, it’s swing music but with a lot of electronics and synthesized mixed in. It’s really fun. So, those are my picks. CHUCK:  That sounds cool. Alright, so I’ve got a couple of picks. I’m a Mac guy. I’ve been really tempted though to buy a PC for my laptop and then just have Windows and Linux dual-boot on there. But anyway, on the Mac I found some calendars that have made my life quite a bit easier. One’s called Fantastical. And the thing that I really like about it is that it has this entry, a text field at the top, and you can just type in what you want for your calendar. It will fill it in for you. And so, basically what I’m saying is I can basically say, “Have lunch with Tim at 12pm at Burger King,” and it’ll actually fill in all the right fields with all the right stuff and put it on my calendar. Or if I have a client that tells me they want to meet at 1pm Eastern Time, I can actually put that in, “Eastern Time,” and then it will put it in my calendar and adjust it for Mountain Time, so really, really handy. And then the other thing that I found related to this is I’ve been using BusyCal, which is a Mac app. And it just allows a lot more flexibility than it would on Google Calendar. So, I’ve got my weeks stretched out to eight days. So, it starts today and goes until next Tuesday. We’re recording this on a Tuesday, if you didn’t know that. And so, I can see what’s going on for the next week. And I can see all my appointments and things like that. The other nice thing about it is that it has the to-dos in the right hand side. And so, I’ve been putting stuff in there. “I need to get this done today. I need to finish this thing. I need to do this.” So for example, I’m speaking at Utah Code Camp on Saturday. So, in today I’ve got, “Practice one of the talks.” And then turn around and I have to actually finish the slides for the other talk. So, I’ve got that in there. And it’s set up for today, and if I don’t finish it today, then it’ll just roll over to tomorrow, which is something that I really like. The other thing that it does is it puts the weather in at the top of the calendar. So, I can see what the weather’s going to be over the next seven days. So yeah, so those are my picks. And yeah, I don’t think we have any other announcements. So, we’ll wrap up and thanks for listening. We’ll catch you all next week. [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]

Sign up for the Newsletter
