The Changelog: Software Development, Open Source - Tedit, JS-Git, Jack (Interview)

Episode Date: July 16, 2014

Adam and Jerod talk with Tim Caswell about getting started in open source, exploring new frontiers, and his latest project Tedit -- a development platform that makes programming JavaScript easy and more accessible.

Welcome back everyone. This is the changelog where our members supported blog podcast and weekly email come up fresh and what's new and open source. Check out the blog at the changelog.com or past shows at five by five dot TV slash changelog. And you're listening to episode 124. Jared and I talked to Tim Caswell about getting started in open source, exploring new frontiers, and his project, T-Edit, a Git-based development environment. Today's show is sponsored by DigitalOcean, TopTile, and SnapCI. We'll talk to you a bit more about Top Tile and SnapCI later in the show, but our friends at DigitalOcean are a simple

cloud hosting provider built for developers. In just 55 seconds, you can join over 150,000 developers who deploy to DigitalOcean's SSD cloud. DigitalOcean offers a fantastic user experience handcrafted by developers. Enjoy the ease of use

and speed of an SSD-only cloud, create droplets, manage your DNS, build a new server from a snapshot, save a ton of time installing Rails, Docker, GitLab, and more with one-click installs. You can even scale your infrastructure with the intuitive API. Sign up today and use the code CHANGELOGJULY to get a $10 credit when you sign up. Head to digitalocean.com to get started. And now, on to the show. We're joined today with Tim Kaz. We'll also have the managing editor, my sidekick in crime, Jared Santo on the call too. So Tim and Jared, say hello.

Hey. Hello. So Tim, you're no stranger to the changelog. You used to be a contributor to the changelog back in the day when we were still on Tumblr. And it's a different changelog probably, but still the same mission. But you've been on the show before. You started How to Node and several other things. You're prolific and open source. You speak at many conferences. So you're not a stranger to the world. But for those who may be coming to this podcast brand new that don't know who you are, can you kind of tee up whom Tim Caswell is?

Okay. So I guess the best way to describe me is I like to invent things. I love open source, and I love enabling other programmers. A quick background is I programmed in Commodores and Cubasic for a long time without internet, without help. And I was blocked by limitations of the platform. Nowadays, we have incredible amounts of technology and ability. And the main thing blocking people is just they think things aren't possible. So I basically spend every free moment I have finding something that is impossible and making it possible. So I author a lot of libraries,

a lot of infrastructure code, and a lot of educational content. So pretty much anything related to that. I've worked a ton with the Node.js project since the very beginning in 2009. I've worked on WebOS. I worked at Cloud9 IDE. Of course, we're going to talk about my recent work on the show. I mean, basically, I've done web development since there was a web, and I like enabling people. What do you, just I guess pausing on that for a second,

considering that you've been developing for the web since there has been a web, what do you think, what kind of, I guess, quick advice would you give about open source to some of the newer people that are coming to open source, let's say, in the last five to six years? That's still kind of older but new in comparison to your time frame. What do you think has changed, I guess, to the degree of access to information? So, yeah, I mean, first of all, there was the the internet which made a world of difference and then for a long time it was central systems like w3 schools was actually where i learned a lot of web tech and as much as we make fun of them it was the content i had and so it worked but nowadays we have all sorts of blogs and podcasts and videos and we have better documentation sites.

Microsoft has a good one. Mozilla has a good one. There's lots of stuff out there. I mean, you can learn from anywhere from individuals to large companies and there's just a ton of stuff as far as learning goes. Now, as far as the community involvement, that's where it really gets interesting. What I, what I tell people is I'm just a guy from a small town in Texas. I was nobody until I started writing a blog. And once I started writing a blog and people found out what I write, it was right. It was interesting. Suddenly I started getting these job offers. I ended up in California working for HP and, and all sorts of things happened.

Anybody can be successful in web development if they have passion and if they're willing to volunteer a lot of free time and to help in open source. It pays back hugely. I'd like to help us navigate that conversation because the, you know, I guess the word free can scare some people, but open source is maybe an easy way to say free and make it cool. I guess, at least today, like open source is becoming more and more cool to be a part of. And obviously it has its own gains and benefits, which you can definitely allude to, but you know, it can be a scary word to say free. So open source time, definitely giving back to the community. Plus a lot of what people are jumping into these days are frameworks or platforms that have been, you know, getting the tires kicked for years by the community and, and it's freely accessible to them. So why not give back? Right?

Right. Yeah. I mean, some people like to work on frameworks. Some people are more like me and just want to make things from scratch. I mean, there there's a place for all types of people in open source communities at which point did you feel like you had like quality content to give back because i think a lot of the the lack of confidence for people just getting started is i have a lot to learn maybe it's a little bit of the imposter syndrome like what could my blog possibly provide to the community that's of value? Did you have a certain point where you're like, you just hit a confidence bump and you're like, all right, I'm just gonna start writing online. I'm willing to put yourself out there.

Or, you know, did you do it too late, too early? What's what's advice for people getting get into that point? I think I'm I'm not normal in that regard. I mean, I started out programming when I was, I don't know, seven. And so by the time I graduated high school, I'd already tried and failed at a web startup. And I was pretty confident in my abilities, probably too confident. I look back at that code and I'm like, oh my gosh, did I actually think that was good code? So I didn't have that problem.

I thought I was really good. And now as far as the social aspect, I mean, I have mild Asperger's. And when I was in high school, I would literally be the kid who runs to the front of the school line with my long sleeve winter coat and shorts, eat my lunch, and then run to the library

and read books about building catapults. Like that was me. And then somewhere in there, I changed from that to I joined a sports team, got good at swim. And then what really helped is I went on a mission for my church where you spend all day going door to door asking people questions about their life and religion. Now, if that won't break you out of your bubble, I don't know what will. So, I mean, I don't know.

So at that point, writing your thoughts online was nothing in context. I mean, I still get a little stage fright. My first conference talk was in this movie theater in Stockholm, Sweden. And I just remember being on stage with spotlights in this room of hundreds of people, and I can't see them.

And it was a little nerve wracking. Wow. But what helped me a lot actually was meeting with the Dallas RB user group and doing lightning talks and just starting there. Like that did wonders. I've been to that group once or twice. I work at a nonprofit called Pure Charity. It's my very passionate day job and

every once in a while we'd be in Dallas hanging out and we'd be there with Karthik and Wynn and Jesse who are probably names you know

that go to Dallas RB so that's a good meetup too. It is. They do really well and yeah, I mean,

that helped me. That helped ease me in because there's a big step between I'm giving a lightning talk to 10 guys I know and I'm on a stage with hundreds of people in a foreign country. I couldn't imagine that stage. So, you know, a little confession on my side, I would probably not be very happy at all being in front of that many people with stage lights on me. I would probably just rather be in the the crowd as odd as it might seem running a podcast that's like yeah it's it's easier to be behind the mic in the seclusion of my comfortable office than in front of hundreds and hundreds of people it's just

not my place you can you can always edit it too so yes yeah let's to some degree we try to as best we can we try to put this one down from from live to tape, as they say in recording. Nice. I was going to say, you're obviously doing a lot of JavaScript nowadays. Could you take us through your language progression through the years? Sure. Yeah, I don't want to spend too much time on it, but basically, I did BASIC for a long time. A long, long time.

Like I said, I started on Commodore on commodore 64 basic which is awesome because that thing had no memory management at all you could just poke random spots in memory and things would happen and then and then i got a dos computer i had this this lovely little 386 with 16 megahertz and 16 megs of ram and i programmed on that thing for about 10 years just that and the cubase agreed me was my entire world so like age 7 to 17 ish yeah and then the internet came out yeah exactly and that changed everything i think it's important to mention too just um just from a a passionate standpoint i guess maybe some inspiration or some encouragement is that you attacked this passion for programming when there was no information.

So you had no choice but to hit the brick walls and hit the hurdles and find ways yourself to get over them. We live in a world now where if you hit a hurdle, you Google it, you likely land on Stack Overflow to some degree, maybe somebody's blog or a doc somewhere, maybe. There's a lot of information accessible to people to get over those hurdles. So it's building that confidence, I think, is a lot harder today

because you're always second-guessing yourself. And maybe to some degree, could you quickly touch on maybe that for you, like gaining confidence on your own? Okay, I think. So there are always unsolved problems. I tend to do things that haven't been done before because that's what interests me.

And I hit a lot of roadblocks, even in today's world. I will be, for example, today I was trying to figure out how to store binary data in Safari. And a few people have tried this. The Lawnchair and PouchDB people have worked on this. They're like, yeah, you can't do that.

You've got to base64 encode it and use WebSQL and crazy stuff. But sometimes I'm doing things like a Chrome packaged app, and I'm testing these APIs that no one has really used before, or has used much. Or the GitHub REST API because I can't do real Git protocol to GitHub. And I find bugs everywhere. I find bugs in Chrome. I find bugs in GitHub.

And there's nothing on Stack Overflow about it because no one's really tried this yet. So there's still plenty of frontier out there. You just have to do things that haven't been done before. So I would imagine you're probably on the happy but yet sad list. Oh, another support request from Tim. He found another bug. Gosh. I have no idea. So since you're an inventor and you like to hit the unknown, it probably tees up what i think is the meat of the conversation so um just to quickly touch on js get get browser t edit or some might call it tedit which was me prior to listening to your super awesome youtube demo of that which blew my mind so i mean what's the best way to tee up what you've what you're doing now with t edit and the kickstarter you did for js get and the like you said the infrastructure tools you need to actually pull this project off.

Right. I'd like to start with the goal. And the goal is a very ambitious but simple goal. I want to make programming accessible. And what I mean by that is we have all these devices in the world that kids and teenagers have access to that are consumption devices. We have iPads and Android tablets and Chromebooks and who knows what else. Maybe you're on a school computer or a library computer or something and it's a lockdown environment. But they all have JavaScript. They

all have a web platform. All of them. And so my goal is to build a full professional developer environment with everything, with dependency management, with build systems, with Git, check-in, check-out, clone, merge, all of that, to work in this restricted environment. And I want to do that so that more people can get into programming without having to go out and buy a MacBook Pro or a Windows PC or something. So that's the goal. Now, with that goal, there's a whole lot of subparts. I am inventing a new language. I'm implementing Git and JavaScript. I'm making a prototype of this developer environment. And so that's what all these projects are.

One of the biggest technical ones was some sort of version control and interacting with the outside world. And nowadays by far the most popular version control system for open source is Git. And so I've been working on implementing Git in JavaScript because then I can use it anywhere. And so,

yeah. Well, that brings us to the, I guess the first hurdle you hit was you couldn't do T edit unless you had JS Git. Can you talk about, I guess, the exploration, the inventor side of you to know? I mean, there's obviously a lot of wisdom and discernment in your choices too. I mean, you can see that given your path. You crowdfunded JS Git

twice. So maybe take us back to, you know, you said you have a goal. How did you begin to think about that goal and figure out what you needed to get in place to actually meet it? Well, the way you eat an elephant is one bite at a time. And it's very easy to get overwhelmed when you have large goals like this. And so I figured, what is a large, substantial thing that I need for this that just needs to get done? And I decided about a little over a year ago that I needed Git. And if I had Git, that would enable so many things. And so I tried working on my free time and didn't make any progress. I looked for existing code and there was nothing

that had what I needed. I mean, there were several attempts. I'm not the first person to try Git in JavaScript. There were many, many attempts. But nothing had what I wanted. And so one day I just came to the conclusion that I have to do this full-time, and I have to find a way to fund that. And Kickstarter was a little new and still pretty exciting back then, so I thought I'd give it a try.

And that's where that started. So there were two Kickstarters for JSKit? There was a Kickstarter, and I didn't ask for near enough money because I misunderstood how it works. I wanted to ask you about that goal, because I've heard some kind of behind-the-scenes horror stories from some people like, I didn't ask for enough, or...

Yeah, so... So, I mean, obviously, implementing Git in JavaScript is, with my skill set, roughly didn't ask for enough or yeah. So, so I mean, obviously implementing get in JavaScript is with my skillset, roughly a year full-time work. I mean, it's not easy at all. And I asked for what I asked for 12,000. That's not a year of salary. I have three kids in a house. I mean, that's not going to work. Right. So what I did was I calculated, okay, I have these consulting projects and if I cancel them, then it'll take me a month or two to get new consulting things. If the Kickstarter doesn't work out or whatever. And so in Kickstarter,

they say, what's your minimum? What's the least you're willing to accept to make it worth your time? And I said, well, I'll do 12,000. That'll give me enough that I can live on a reduced budget for a few months. And that makes it worth it to fire my clients. And so I put that as my minimum. And here's the problem. Everyone who was funding it thought that was all I needed. And so it hit the minimum overnight. Like overnight it hit.

It was because it was very exciting. People love the idea. But as soon as I hit that, it just crawled to a halt. And I set stretch goals. I explained to people, no, that's the minimum. If you want all these things implemented, I need a lot more. And it didn't work. So I worked on that.

I stretched it for as many months as I could until it was endangering my family. And then Bounty Source came to me and says, hey, we're like Kickstarter, but specifically for open source projects, we will help you. And they did. They went out and helped find funding from corporations. They handled all the stickers and T-shirts and everything. Wow. They just charge a fee for the service, which I thought was well worth my time. Because when I was doing the Kickstarter, I spent an entire month and a half full-time fundraising.

And that was half the money because I barely got enough. So that was almost a waste of time. So the JS Git one in Bounty Source raised $34,000, just a little over $34,000 of your $30,000 goal. That's neat. I knew about Bounty Source, obviously.

I think we've had Michael Peace on the show before. He had an RVM fundraiser there. I'm not really sure how you term it. A bounty source there, I guess, because you would use the brand name of the platform like a Kickstarter. I don't know. And then you got your $12,000 goal that you even over exceeded. You had four or five backers on Kickstarter kickstarter which uh looking at the time frames

trying to figure out what the time frames were between the two was it about five months between or a few months between kickstarter and bounty source something like that that sounds right so i mean you got twenty thousand dollars so what happened when you got when you first get your first crowdfunding from kickstarter did you you fired your your clients and went to work for two months? And then what did you do? Yeah, I worked and spent most of the months just trying to solve the cross-platform issue, which was the first thing. Because

the JavaScript module ecosystem is terribly fragmented. And the goal of JSGit was to have this platform that runs anywhere. So I had to run on the Chrome app platform, on the web platform, on the Firefox app platform, on the Chrome app platform, on the web platform, on the Firefox app platform, on the Windows app platform, on Cordova,

on pretty much any JavaScript platform you can think of. And so I spent the first several months mostly figuring that out. I mean, I did some get specific code here and there, and a lot of it was finding out what existed and how I could use it.

But I'm going to admit, a lot of that time was spent trying to find a flexible way to work with all these systems. What's the biggest hurdle between all of them? Just the fact that they're just different, they make different choices, or how they store data, how they deal with databases? I mean, that kind of stuff you can abstract away. The trick was, how was the best way to abstract that?

What kind of dependency injection do I want to use? What kind of module system do I want to invent? Because I can't use anything existing. A lot of people told me to just use Browserify, which I understand if you're on a desktop platform, that's a great choice. But I'm specifically targeting platforms that don't have a command line, that don't have Node. node right and so I want to be able to develop on these machines not just

consume on these machines that was the entire point and so I can't depend on a tool chains that need a desktop machine so basically there was nothing existing I could use yeah it's like all these you might be able to learn something from some of them or at least see what their what their goods and bads are, I guess. You know, what their fails and successes were to maybe learn from that. But otherwise, you're kind of hanging out in uncharted territory. Right. I mean, I use browser-fi-style transforms.

I write all my code as common JS modules, and then they're compiled to whatever I need for the target. But all these transforms run in WebWorkers, or if I'm a node, they run in something else, but it's all implemented in the T-Edit platform. Let's pause the show for a minute and give a shout out to our sponsors Snap. Snap is a hosted CI and continuous delivery service that goes far beyond letting you do continuous deployment. Don't waste your time and set up your own CI box under your desk. Use Snap. Snap has first class support for deployment pipelines. With Snap, you can push any healthy build to multiple environments automatically or on demand.

This means with Snap, you can do things like deploy to your staging environment today, verify it works, and later deploy the exact same build to production. Snap integrates deeply with GitHub, has great support for lots of languages, databases, and testing frameworks. Snap deploys your application to cloud services like DigitalOcean, Heroku, OpenShift, AWS, and many more. You can also use Snap to push your Ruby gem to Ruby gems. And Snap is always free for open source projects. Try Snap for free for 30 days today. Sign up at snapci.com slash the changelog. Well, since you teed up T-Edit, you know, you did JSGit. I guess out of the box, I'm,

you know, I want you to explain what it is for one. And then I guess a follow-up question to that would be why no crowdfunding for T-Edit, but there was crowdfunding for JSGit? Okay, so on the crowdfunding, it did not go so well the second time. The bounty source, I set a much higher goal. I set a much longer time frame because I learned that the companies can't get from idea to approval within a couple weeks. They just don't work that fast. Like Brian LaRue and some other people at Adobe were trying to help me get Adobe funding. And they're like, look, if you give us a week of warning, we're got a really hard time getting you that money. So I set the goal longer.

I set the money higher and I traveled. I went to California. I talked to people at all the big companies and I was getting nothing. I was several weeks in, and I think I just had a few thousand dollars, mostly from individuals who funded me the first time around and just liked me so much they wanted to do it again. That's not sustainable. At the last second, Mozilla bailed me out and paid the bulk of it with a grant. Wow. But I learned from that that I can can't live longterm on crown funding.

It helps you get an idea off the ground. It helps you discover if people like it, but I don't believe it works longterm. So what was the feedback from the individual companies on T edit? Did it just not align with their particular goals like JS get did, or did you have a hard time delivering the vision? Well, I didn't even try to fundraise to

get it so i don't know oh okay the bounty source was still js get gotcha but the the feedback i got from several of them and one of them just just bluntly told me he's like look my generation of managers does not understand giving money to an open source project if we give you money we want a contract in place and we want exclusive ownership. And I was telling them, no, this code is open. This code is freely available to anyone. And they're like, so you want me to give you money so my competitors can benefit?

I'm like, yes, because if you don't, it won't exist and it benefits you too. And they're like, nope. You think there might just be a generational gap there, or maybe it's just case by case? I think so. I mean, Mozilla obviously donated the most twice, but they're a non-profit whose goal is the open web. Right. And I'm doing something cool with JavaScript.

Like, they don't actually need JS Git. They just thought it was cool that I'm doing something with JavaScript. I think Adobe was the only company who actually had a use for it that donated, because they were thinking of using it in brackets and something with some other stuff. That's tough. I mean, Jared, you asked, is it a generational gap or is it something else? I think, yeah, if you don't have the right person who cares and really understands, and I think that's kind of what we try to do with this show is to not just talk about the projects, but also the people behind them and the motivations and their aspirations. And like you had said before, the goal behind this project is pretty audacious and it's uncharted territories. And shining a light on that is important because

there's a lot of benefit that can come down the way from all this learning that you're doing and what it gives back. But we have a passion for open source. We understand the community and it's a lot harder to sell that to someone who just doesn't get it, just doesn't care. Maybe they, maybe they get it. They just don't care. And given a lot of money to something and not seeing in quotes, the ROI is, is really tough. We, we face that battle here and there too, ourselves. Yeah, it's tough. I mean, there were companies which I know benefit a lot from what I'm doing and I couldn't get them to fund because that's just not their policy.

That's not how they work. So is T-Edit totally nice on weekends and you're just full-time somewhere? At the moment, yes. So around New Year's, the JSKit money almost dried up. And so I made one last sprint i was going to try to make a product that used js get and i could sell that product i was going for the

business route maybe like maybe i could fund it that way and so if you look at my github history you'll see i worked insane over time the first couple months of this year and i was basically just building t-edit from the ground up. I tried a web version. I tried a portable version. I got stressed and just focused on a Chrome app only version. I just threw away all the cross-platform stuff. I got pretty far in the Chrome app version until I finally was really out of money. Right now, I'm doing consulting work. I work on T-Edit when I have time, but the progress is way

slow because I had to stop. See, I was going to ask you about the, the Chrome app piece, because you talk about, you know, open cross platform. And then I look at it, it's a Chrome app. And I thought this doesn't seem to line up with his goals, but it seems like it's just a, just a time and money decision for now. Well, and there's many versions of it this week actually i i made i made a little time and t-edit now runs on chrome and web nice so if you go to t-edit.creationx.com that's the web

version and if you look in the source tree it's the exact same code there's just a few parts where it swaps in some platform primitives and turns off some features. So for example, in the Chrome app, I can access the file system. So I can read and write files. I can, there's one feature where you can export your T-Edit build system final files, like the built files to the file system. And so you can use a Chrome app to make Chrome apps.

Or I've used it for node development before. I also say before we dive deep in, I know that T-Edit is probably a rough concept for most anyways. Maybe you could tee it off by, you know, you mentioned the goal of programming being accessible to everybody, but can you kind of give us what exactly is TED? Kind of give us the high-level overview. Let's start diving into some of the details around what it does

and how it works and where you see it going. Sure. So yeah, JS gets just a library. It was just a means to an end. And then T-Edit itself is the developer environment. And the goal there is, is I want to, I'm thinking of two main use cases. One is me. I like being a random machines, like my Chromebook pixel, for example, or who knows what else, Maybe my Android tablet. And I want to be able to do work there. And then kids in my programming class or just anywhere who are learning, I want them to be able to use any machine they have. I chose Chrome app for now because it's everywhere nearly.

If the machine has Chrome, it can run Chrome apps. So that's all laptops, including Chromebooks and desktops. And there's a lot of Chromebooks in schools. I thought lots of kids had them. Maybe that's not true. I don't know. And then two, the platform is very powerful. It gives you primitives the web doesn't have. I can access the file system. I can make a web server. I can get around the cores restriction and talk cross domain. You have all these extra primitives that the browser doesn't have. So the Chrome app that's in the store right now is basically an IDE that edits Git repositories directly. It does not edit files on disk.

And this is a very important distinction between T-Edit and all the other editors in the world. In everything else, Git is a tool you use on the side that creates a working directory, and then your editor works with those files on the hard drive. And then when you go back to Git, you pull those files back into the Git database. Whereas in T-Edit, you never have a working directory, ever. You always work directly on the Git database. So it's a slightly different way of working. Hmm. Does that make for a better user experience or more approachable than the traditional way?

I'm still exploring that. One of the things that I've found that I really like so far is I found a way to make submodules not suck. Really? Yeah, because the concept is not wrong. The UX in the real Git client is terrible. It is horribly

terrible. And this is why people don't use submodules, because they'll bite you. Yeah, I mean, I've personally given up on them a while ago, so I don't even know what the current state of submodules is. Nothing's changed. No, nothing's changed. It's the same.

No one works on it as far as I know. Okay. But the main issues were, one, it doesn't record the branch you're working on. The way it's actually implemented is very simple. In the tree blob for that file listing, it's just type commit, and then the hash is the hash in the other repo. That's it. No other context. It just points to the hash in another repo.

And then in the root of your project, there's a get modules file that maps that path to a remote URL. And that's it. So by default, in the normal client, if you change anything, you get thrown in a detached head state. And then if you move some stuff right in the parent repo

it'll revert your code without even warning you and your changes are gone. And if you forget to push the submodule and then push the main one it'll point to a commit that doesn't exist on GitHub and it's a nightmare. So how do you fix it? So with T-Edit, everything

is one big continuous virtual file system. And sub-modules are just mapped in like you do in NFS or Samba Mount, and you can just browse them as if they were local files. And depending on which backend you're using, it works really well. I have a GitHub backend

that actually mounts the repos using GitHub's REST API and uses GitHub as the data store instead of a local data store. I have a local cache to make it faster, but all the real actions happen directly on GitHub. And so suppose I edit a file in a submodule. I will then save that blob to GitHub,

which gives me back a hash. And then I modify the parent tree to say, hey, it points to this new hash, and then I save that and it gets a new hash for the parent tree, and I do this all the way up to the root tree. And then once the root tree has a new hash, I create a temporary commit pointing to that root tree. And then

in the parent repository, I update the submodule entry to point to that new temporary commit, and then this prop gets all the way up to the root. So anytime you change anything in a t-edit tree, it's saved all the way up to the root. So anytime you change anything in a T edit tree it's saved all the way up in all the parent

repos. And so if you knew the hash to the temporary commit you could see all these temporary state of your files in GitHub. But that's all in the background.

You don't actually see that temporary commit. Right. Since I don't actually move the reference, I don't actually move head, none of it's visible. And in fact, if you don't commit it within two weeks, it'll probably get garbage collected by GitHub's backend.

So you don't want to be in this state for a long time. I commit my code every day just because I don't trust my local machine and not eat my code. Is this keying off of the... Just watching, we'll link out to this too, so if you're listening, we'll have this YouTube video. We're going to mention, we mentioned earlier

Tim's awesome demo of this, which was very enlightening and mind-blowing, but you said in the video it's always committing. Is that kind of like committing to your local Git repository and then finally doing a final push whenever you want to do a commit of that code? Is that kind of like a rebase of that or whatever to kind of munch it into one commit?

Is that what you're doing or is that something more unique than that? No. So like I said, when I'm using the GitHub backend, your JS Git instance is a proxy to GitHub. There is no local database. There is no clone. There is no pool.

There is no fetch. There is no push. You are literally modifying your data on GitHub directly. Like, if you open up the terminal, you can see REST calls just flying back and forth. But it actually performs pretty well. So how does that handle offline? Does it just queue them up and wait? It doesn't.

Or it doesn't. Okay. I have a task for that. Okay. Because I want offline. Well, some of this is offline, though, right? I mean, you've got a lot of this that's offline and secure. I heard that a couple times in a video.

Can you talk about that? Is that a good time to talk about that? Sure. So the backends, there's lots of backends for JSGit. There is no one backend. The JSGitHub backend is the one that live mounts GitHub repos. it's the one i use the most because i don't have push and pull implemented and so i can't sync and so i just use that one but once i implement the network protocols the other backends will work great there's an index db backend i was working on a web sql backend this

morning there's i had a local storage one, but I don't know if it's still maintained because there were some issues there, mostly with just limited space. If you're a node, I have a backend that can read and write real Git repos off disk. So it implements that format, that.git folder. I have the same thing for Chrome apps

because Chrome apps can access the native file system. So you can mount a native get repository using a Chrome app, edit it and T edit, and then push it from the command line. If you have note or if you have get, so there's lots of backends and it's very flexible. There was, I had people talking to me.

One company thought about using S3 as a backend And all I really need is a key value store. That's the bulk of what Git needs for its storage. So it depends on what performance you want. You can use anything as the backend. But yeah, I haven't implemented push and pull fully yet. I haven't implemented merge or diff. And those will be on the JSGit side, right?

Not on the T8it teta side yeah they're part of js get but teta will use them it'll it'll expose interfaces for them and yeah that's that's where i was when i ran out of money i was i was implementing that stuff and then i couldn't get done so you mentioned your you ran out of money where what is the state of this project right now i guess from uh obviously you're passionate about it. So that, that kind of goes without saying, but you know, are you out of money? What's the next step to giving yourself the necessary time to keep building this? And I guess, what is your direction? So I've got some consulting work till end of June. And after that, I'm going to take another run at it, see how much I can get done, and see if I can find more novel ways to fund it.

I don't know yet how I'm going to do that. I'm just trying to survive and get there. Some ideas I had was T-Edit consulting, where people would want to use JSGit or T-Edit in their product, and they could pay me to integrate it into their platform. And I found some interest there from a few companies. I could do one. One thing I really want to do back to my original goal is I want to make games. I want to make simple games, make them open source and then write docs about how to write games. So these kids can get into programming. And I was thinking about maybe selling podcasts or tutorials because people seem to want to pay for that.

What I don't want to do is I don't want to charge for the code because I'm essentially writing infrastructure and infrastructure should not be for pay. It should be freely available because it's just code. It's not going to cost me anything to copy it. So I want T-Edit and JSKit

and all the code itself to stay open-sourced, MIT or Apache, something very liberal, and find other ways. I've considered another fundraiser, but like I said before, I don't think that's sustainable. Well, especially if you've been through two

and the second one even had the help of BountySource, still had to be the final bit taken care of by Mozilla. And big shout out to Mozilla, too. I'll give them a thanks. I know you already have, but on the show, that's awesome to support Tim like that. Yeah, they're awesome.

Tim, you mentioned in the video that we keep mentioning your demo, a pro version. Is that on the horizon? Is that something that you're thinking about? You just mentioned free code and no charge for infrastructure. So does a pro version fit into that? I don't know. I've sort of scrapped that idea.

I do still have a hosting platform I've been developing, and that's actually my only private repo on GitHub. And we haven't talked about the T-Edit build system yet, but... Yes, that was pretty neat. Who? High level, it's a build system like Grunt or Gulp or whatever,

but it works completely different, and you don't need a command line. But this same build system I've implemented in a Node web service where I can host your T-Edit-based web apps, and it's basically GitHub pages, but with a bunch of smarts baked in. So one idea is I could charge for that hosting,

because it's a service. I don't mind charging for services. I just don't want to charge for the infrastructure code. But hosting's a hard thing to make money from. The build system that you mentioned, is that where you were piping into, like, AppCache and the other tools that are available to build something? Because you used T-Edit to rebuild another version of T-Edit. Right, right.

So let me go into that. So the original goal was I wanted a full development environment. So once I have Git done and I've implemented push and pull and merge and diff and all that fun stuff, I have version control, I have sharing, and I've done dependencies with the easy submodules. I can add a package manager on top of that that just eases setting up these submodules. But you still need a way to build files. In modern web development, maybe some people use CoffeeScript. Maybe you like writing CommonJS, but you're running in a browser. You need build steps. And so the T-Edit build system is kind of unique. The way it works is you create these rule files.

I think there were some links in the video. But now they're rule files,.rule. They're actually written in John, which is a subset of Jack. JSON is a subset of JavaScript. They look like JSON. They're just a little more flexible. You basically say, you take the file that you want to exist. I need an app cache

manifest, or manifest app cache. Then you add.rule to the file name. Mark it as executable because you can do that cross-platforming Git, because I'm not using real files. And what the system will do is when it sees an executable.rule file, when it's serving over the web or exporting to disk or going through anything that needs the built version of the files, it will execute that rule.

And the rule itself will be an arbitrary program that user writes. And I'm going to maintain a library of some useful things. And so these are the equivalent of your, your Gulp or Grunt plugins. And so I have one called AppCache and you give it a listing of files. And what it will do is it will search the Git tree, the built version, find the E tag of all those files and append them as comments in the AppCache. And if you've worked with AppCache before, you know that the file needs to change every time find the E tag of all those files, and append them as comments in the app cache. And if you've worked with app cache before, you know that the file needs to change every time any file, it depends on changes.

And so that way, you don't have to constantly go update some timestamp in your app cache. So when you refresh in the browser, it automatically grabs the new app cache, and you always have the latest code. And there's other compilers. There's the one I just built for my cross-platform stuff.

I called, what did I call it? JS compiler, something really, really plain. But what it does is it takes a tree of source code that's in common JS node style and then builds it as a bunch of AMD modules. And then I have a really, really minimal AMD loader that injects those as script tags in the web page and loads them on demand.

And I'm going to add another version that builds a single concatenated file for websites that want to work offline. And so what you'll do is you'll have all your JavaScript in the one big concatenated file, and then your app cache manifest will point to that file. And then anytime anything changes, the tag of the big file will change, which will then cause the app cache to change.

And so you'll have automatic concatenation. We can throw in minification. You can have any other filters you want. We could do CoffeeScript. I have a, I've put Facebook's Regenerator in there because I really like using generators. So now I can use generators in any web app or Chrome app I want. And all of this works without a command line, without Node, without anything. Let's pause the show for just a minute and give a shout out to our sponsor, TopTile.

Now we've been working with TopTile for about a year now, almost a year now. And we thought it would make sense to circle back and talk to some of our listeners who have applied to TopTile and have been accepted. Because only about 2-3% of the engineers who apply make it past their strict elite engineering process. And Daniel Lauzon, a long-time listener and fan of the changelog, is now living the dream. He's an elite engineer at TopTile, and I say living the dream because he's now able to have 100% control of the types of projects and technologies he's working on, as well as the rate he wants to charge. Daniel earns 100% of his income as a TopTile engineer, and he wanted me to pass on his

seal of approval of the TopTile experience. For those of you out there who are freelancing or would like to test out freelancing, you've got to check out TopTile. If you think you have what it takes, head to toptile.com slash developers. That's T-O-P-T-A-L dot com slash developers to get started. Tell them that ChangeLog sent you. You mentioned in the video, too, since you're mentioning Node and NPM, I think you mentioned earlier, on a Chromebook.

So this is, just to kind of recap, this is pointed, right now it's a Chrome app. And I think it seems like, if I'm hearing you correctly, it seems like it's a Chrome app now, not because you don't want to be cross-platform, but because you have limited time and you need to make progress. Is that accurate to say? Well, I need the extra primitives. The web version has serious limitations. Right. I can't get GitHub or Bitbucket to turn on cores. I have asked them multiple times,

and I don't know if they have security concerns or what, but a web page cannot clone from GitHub because it's cross-domain. Yeah, right. Now, there is the REST API, which I use extensively, but it's much slower, and it's proprietary to them, and it's not the same. So with the Chrome app, I have full access to everything.

And also, I can access the file system. I can create a local HTTP server. And so you can write a web app in the Chrome app, host it, start the web server in the Chrome app, and then another tab in your Chromebook, you can then run your web app. And all of the build files will be built by T-Edit in the Chrome app, and everything works end-to-end. And then like you mentioned, you can also self-host the T-Edit itself. So I can build a Chrome app with a Chrome app.

That's awesome. Let me just stop you for a second and say, you're doing some really cool stuff. When I watched that, Jared, I was like, I seriously almost fell over. I had to catch myself. I feel like there are certain people out there that like everybody should, they should just be given a bunch of money and be like, just go do your thing and we're all going to be better off. And I got a feeling you're one of those guys.

Sounds good to me. Well, we're offline. I mean, what I think, I think what Jared's trying to say is you have our full support. Whatever we can ever do to help you, we're going to be there for you. And I'd like to talk to you more about some ways we can be a part of that and just help make your life a little easier if we can. So you touched on the web server part of it. Is there any more we can mention about that? I think it's just kind of unique that it's all-encompassing T-Edit.

It not only is it a full-on IDE, it's headed straight from Git. I mean, this is some pretty amazing stuff. You can run the app itself with it. And I think one other quote you had said, you're not building an editor, you're building a workflow. And it seems like this is, you know,

not only is it, it's got all these complex backend pieces, but you're also able to serve up whatever you've built. And then the offline part that I think you touched on in the video that I'm not sure how accurate it is now, because that was in February, but you were able to kill the current web server and still serve up the game from the

AppCache. Right, so AppCache lets apps work offline. And when I get the web version of T-Edit done, it's going to have its own AppCache. So you can go on an Android tablet, go to t-edit.creationx.com. It'll run today, but you have to be online. But once I

get all of that done and I've implemented offline sync, then you'll be able to add this to home screen. It'll run today, but you have to be online. But once I get all of that done and I've implemented offline sync, then you'll be able to add this to home screen. It'll work offline just like any native app, which I'm very excited about. How has mounting a GitHub repo changed? I couldn't tell from the video how it seemed like you had to like manually type in you couldn't just like what maybe some users at least i was thinking that you might just be able to choose um you know from the repo versus like hand typing in creation x slash t edit i have an app for

example to to kind of and then you also had to point back i think a sha one code can you talk about mounting a github repo maybe how that's's changed since February, if it's changed at all? So that UX hasn't changed much. What that is is it's a GitHub token, and I'm not sure you can GitHub OAuth from anything that doesn't have server assistance, because the

way they've set up their OAuth, but you can go to GitHub and request an app token and then paste that token in. And you only have to do it once to set up your machine and it remembers it. Now, the other part, the paste in the URL, is just me being lazy. There's no reason I couldn't have a smarter UI that, using the

REST API, queries all of your Git repos and gives you a dropdown or some smart selector or whatever. That's a nice to have, not a need to have, right? Yeah, I'm focusing on the things that other people can't do or other people think they can't do. There's nothing I'm doing other people can't do. And just to kind of key off one more thing, I'm not sure if we touched on it, I think, slightly, but it uses Ace Editor.

And it kind of goes back to what I just said, which is what you said, actually, which is I'm not building an editor. I'm building a workflow. So you didn't actually build the editor part of it. This is from an existing open source project that's out there. I think I was going to ask about your Cloud9 experience. I'm assuming you had some part in Ace Editor as well. I didn't actually work on Ace a lot while I was there.

It was pretty much Fabian's work. At Cloud9, I was doing a bunch of infrastructure, backend stuff, making the, like the big thing I did there was I made the terminal run in the browser over a web socket with the lowest latency possible. Ace is amazing. I used CodeMirror for a while, and then I switched to Ace because I prefer it personally. It's a lot more full-featured out of the box, but it's also a lot bigger. So it's a trade-off i liked your your comments too about working late at night near children in low light levels and being able to

easily swap out the various um oh right the various syntax highlighting colors that was pretty neat too so when you open up t-edit you're going to see a nice window at a tree view the tree view is all my code and that's all custom code that's the bulk of the code actually everything's inside that tree and using tj holloway chuck's css parser i parse out the ace theme when you change themes and then apply the same colors to the tree so your entire screen is the same color scheme because like you said i am i am all often working in the dark in a bedroom next to children helping them sleep. And I hate having this bright white tree here next to this dark code here, and it just doesn't work. Yeah, I like that, too. I think those who primarily work maybe in Vim or something like that are used to it because it's all whatever they set for their theme in their terminal. But for those who maybe work in Sublime Text or other, I guess, IDEs,

you generally have syntax highlighting and colors for your code, but then it doesn't really apply to your sidebar, your file system like you just mentioned. So it was neat how those played a part too, and just even easy too how you can swap from one color to another. I think it makes it a little harder in other editors. And for some reason, you just made it so easy. Right.

Like I said, my focus is accessibility. Yeah. And part of accessibility is vision. So one of the first things I did for T-Edit was you can change the font size and the color scheme with keyboard shortcuts. You can change them very easily. So if I'm presented at a conference and I'm live demoing,

I can change it to a white background if it's not a very good projector. I can bump up the font or shrink it down. I want all these things to be extremely easy because I don't want them to get in the way. So those were some of the first things I did. Well, we didn't talk at all about ChromeFS. Maybe you mentioned it, NodeFS. I'm just looking at some of our notes we had for this call.

Before we begin to close out the show, what other things can we mention that you haven't done enough, Tim? So what else is there to mention that's really important to close off, I guess, talking about T-Edit and I guess the direction you're taking with that? Right. We should probably talk about the current state of the project and what people can use now. Okay.

Well, it's not done. And the biggest missing pieces are network and diff and merge. But what is done is a lot. The JS GitHub backend is quite mature. You can use it in Node or WebApp or Chrome. It works anywhere. And that's the JS GitHub project. There's two new ones.

There is Git ChromeFS and Git NodeFS. And what those do is those use the built-in mixin and JS Git, the FSDB, and they let you mount real Git repos using JS Git, either from a Chrome app or through Node. And so the hosting project I was talking about, what it does is it GitHub mounts the projects,

but then it caches them locally using a real Git repo using the Git NodeFS. And when I'm doing my consulting work, what I'll do is using T-Edit, I will mount my local Git repo on my MacBook. And that way I can edit the do is using T-Edit, I will mount my local Git repo on my MacBook, and that way I can edit the Git tree in T-Edit, and I need the files back on the hard drive for Node, and so I live export the whole thing to the hard drive. And so anytime I change a file, it writes it out first to the Git repo and then to the working directory, so I can test my code. There's a few weird things about it, because I now have two copies of everything, but some nice reverts or git resets fix that pretty quickly.

So you can use jsgit today for a lot of things. You can, since you can read and write existing git repos, if you're on a server where you have real Git, then you can clone using normal Git. And then using JS Git, you can mount that repo and use this nice JavaScript API to walk the tree and walk the commits and do code analysis or custom builds or whatever you want. So this could be used for JavaScript package managers or build systems or continuous integration systems.

I want to be able to eventually use it for mobile apps that want a syncable offline storage. And so I have two tasks there that I'm going to work on soon. One is I'm adding sync to the GitHub backend so it can actually work offline and then sync with GitHub using the REST API. And then another one is I'm going to implement the full pack protocol that everyone else uses, that real Git uses, for the platforms that actually have that network primitive. Since you were talking about the, I guess, location of where things like mounting from GitHub, it seems like it's got some deep GitHub integrations.

At one point during your demo, you talked about owning your own code and you feel very passionate about that. Is it where you store your code? What did you mean by that? I couldn't quite understand what you were trying to emphasize with owning your own code in the editor. Is that keying off of where you mount your repos from, like your own private repos or GitHub or Bitbucket? Is it that or is it something else?

So I worked with cloud IDs. I mean, I've worked at Cloud9 for a while. And the biggest issue I had with them is your entire workspace lives on some cloud server. Right. Which, I mean, first of all, that's a practicality issue. You have to be online. And that's a non-starter for me.

I have flaky internet. I travel a lot. And then it's on their cloud server. They can read it. They can write it. They have full access to your code. They have your GitHub token. They can write to your GitHub. I don't think any of these companies are malicious, but just from a security standpoint, you don't want anybody with that much power. They could be corrupted. They could be hacked. They are now a hacking target. Whereas if everything lives locally in your device, and you just push to GitHub or Bitbucket as a public mirror, then it's different.

You are now in control of it, and you control who has access. And also with JS Git, it's not hard at all to write your own services and your own hosting. As soon as I get some of this network syncing stuff done, it'll be trivial for people to host their own Git repos and even mount them off their own servers. Because the live mount is really convenient if you have large repos with lots of sub-dependencies.

You don't have to do recursive clone. You just instantly mount and everything's available. I was going to say, it seems like for the most part, GitHub is very popular because of its collaboration around open source. Not so much for being a Git hosting platform. That's how they started, but they popularized social coding, so to speak, and obviously are responsible for a lot of the big push and adoption for open source and maybe even some growth. Maybe somebody's going to punch me in the face for saying this, but just growth in the developer ecosystem.

You can't not recognize their power and their push for this. So I just kind of wondered. It seems like because TI is so easy to use in this respect by mounting a repo, it doesn't really have to live on GitHub. It's just that's your means right now. Right, and you can use the web version today, mount a GitHub repo, it doesn't really have to live on GitHub. It's just that's your means right now. You can use the web version today, mount a GitHub repo and edit it. So if you just want a quick way to edit your Git repos,

just go to tedit.creationx.com, paste in your token and edit anything at will. We've got several links that this will be a link-filled show notes episode. So if you're listening to this, go back to the changelog find the episode i think this is 124 if i remember correctly um uh and are also on five by five the

the links will be there or even in your podcast catcher so we'll we'll share tons of links so if you can't hear us or you weren't sure uh check the links we'll we'll have a bunch of show notes for this but uh jared is there anything else you want to mention before we start closing off the show? Well, I did want to ask about Jack, but I'm not sure if we have time to even do that. We might have to have him back just for a whole entire show. Maybe you can do a quick overview,

and we'll have you back to talk about Jack. All right. Jack is a fun project. My goal there is to make a language that's easy to learn, yet powerful. It's basically a mix of JavaScript and Lua. And I'm really excited to actually use it someday. I haven't had time for it yet.

So is it backburnered because of T-Edit at this point? It's way backburnered. I've been working on it since before CoffeeScript. Wow. That's a long time. Yeah. And then you also mentioned John, which is, I guess, a sub-brother?

Sub-sister? I guess sub-brother, right? Sub-set. Sub-set, yeah. It's Jack object notation. Okay. So John is to Jack as JSON is to JavaScript. So in T-Edit, all the config files

and that one file that opens up with the instructions, those are all basically John format. So it's just a subset of Jack that's the data format. And it's a strict superset of JSON. So you could write JSON and that would work, but the quotes are optional, the commas at the end are optional, you can have comments inline. It's a little more flexible than JSON.

You decided against Jill on that one, huh? Yeah. Didn't fit the acronym. No. Yeah, that's neat, though. So I guess, for one, I mean, I just, I'm not even kidding. When I said I almost fell over with watching your videos, I was like, wow, this is insane what you're doing.

And you're definitely leading the charge in that. That's for sure. So one way we close the show off is we have a couple questions. you're doing and you're definitely leading the charge in that that's that's for sure so um one way we close the show off is we have a couple questions i don't think we had these questions whenever you first came on the show back when you're talking about lua i think in the early 20s of the changelog um but one one question we ask and you may have already asked or answered this during the call but to be blatantly clear what is a call to arms for your projects you know js get i think that's pretty much complete, but obviously you're probably still

accepting code to that. But how can the general public listening to this either step up and help you code-wise, issues-wise? How can the community step up and help you? So it's to the point where other people can code without getting in the way. I have a lot of issues. What I really need is, starting in July, if your company is interested in using this, you can hire me to integrate it. And I promise that almost every company that involves data or dev tools can use this in some way.

So if you can get your company to hire me to help integrate this to add the features you want, I want it to kind of work like the CMirror or LuaJet projects where they have corporate sponsors who add features and then everyone can use the code. And what's the best way to get in touch with you? You got creationx.com is your homepage. We'll have that in the show notes. Is there a contact button on there? What's the best way to reach out to you? I hope there's a contact button. I don't know. I mean, my email is probably the best. My email is public on my GitHub. It's tim.creationx.com.

Gotcha. Yeah, that works. And I guess the next question, which is usually a fun question. So, I mean, it doesn't have, considering your background, I'm assuming you'll be talking about programming to some degree, but what would you be doing if you weren't doing what you're doing? Good question. If I wasn't doing the JS Get To Edit stuff? Yeah, this mission we're talking about on this show, like, if you wasn't doing the js get to edit stuff yeah this mission we're talking about on this show like if you weren't trying to put all your passion all of your effort and all of your time into that either through your own free time or supported time you know if you weren't doing that what would you be doing i would probably be oh i don't know if i wasn't programming i'd be

making things that's for sure. I make things with paper, with wood, with whatever. If it was computer-related, I'd probably be writing libraries, template engines, compilers. That's still pretty much related to this. I'd be making something for sure. I am always making things. I'm always creating. That's why my handle, the creationix, is the word creation and then IX from Linux from Unix.

I create open things. That's what I do. I was thinking that. The X part kind of gave it away, but I wasn't sure for sure. Yep. I create things and then I open them up. That's what I do. And I guess our last question we ask is,

I don't know if you answered this your first time around, but who's your programming hero? Like who's inspired you? Who's helped lead you? Who's encouraged you? Anybody. It can be one person, could be a couple of people, whomever. Oh, I got lots of heroes. Name them all, that's fine. All right. There's a couple language designers I like. I like Mats from Ruby. He's a really cool guy. I've met him in person. I like Brendan Eich from JavaScript. They're very different people, but I like them both. I'm impressed

with Mike Paul for the way he gets paid to work on LuaJet, even though I know very little about his actual person. He's quite cryptic. I'm going to butcher his name, but the Codemirror guy, is it Merine? How do you say his name?

I don't know. I'll have to look it up. The author of Codemirror and TurnJS and the Eloquent JavaScript book. He is amazing. I love what he's done. Let me look behind me. I have it on my shelf. Yeah, the big yellow book. That book is great. I love what he's done. Let me look behind me. I have it on my shelf. Yeah, the big yellow book.

That book is great. Let's see. I'll try and... I've been meaning to reach out to him, too. I'm going to say Marijan Haverbeck. Haverbeck. Yeah, I'm sure I butchered the name. Yeah, I probably did, too. Sorry about that.

I think he's awesome. So, yeah. I like those people. I think they're cool. Awesome. We'll do our best to do some digging, too, and make sure we get some links in the show notes. I know one reason I like asking that question on the show is just it kind of gives some insight to who inspires you. And they're not always people that are very public, like you had mentioned.

You don't know so much about one particular person just because they're sort of just not very public about what they do. So, but their work is, and that's what inspires you. Yeah, I think that's, that's, this has been a fun show, man. I know that T-Edit, I, again, I'm glad you said T-Edit because I was going to call it Tedit, just based on the, the, the phonetic sounding of it, I suppose. I was going to sound it out versus thinking just T-edit. But Tim, thanks so much for joining us on today's show. I know that we'll definitely help you out if we can.

We'll do whatever we can to also, in the future now or in the future, just promote ways that the community can support you, whether it's through funding or whatever. So if ever you need a friend to help you out, we'll be there for you. But before we close the call, I want to give another shout out to our sponsors, DigitalOcean, TopTow, and SnapCI for supporting the show. Thank you so much for your support. And if you're a listener and you haven't yet done this, subscribe to the ChangeLog Weekly. It's been on a small hiatus, but there's no reason not to sign up because we are bringing it back. We get death threats

and emails daily about where's this awesome email I've been getting and why'd you stop doing it? So we can't stop shipping that. So the changelog.com slash weekly to sign up. Jared, thanks so much

for joining me on the call today and Tim, you as well and the listeners for listening. So until the next time we speak, maybe about Jack, let's say goodbye. See all right see you next time.