What happens when we open up browser APIs like a filesystem? Omar Rizwan joins Henry to chat about his latest project, TabFS! We discuss possible extensions, tinkering with scripts vs being a whole project, writing it yourself, few dependencies, determining your 1.0, literate documentation, and maintaining a newly popular open source project! (26 min)
Conversations may be edited for clarity. (edit)
Omar: It's funny. You know, one thing that I thought was interesting. This is something that Andy said is that like, I don't have much of a use for the project, cause I'm not a big tab user. And I think it's funny how many people have sort of glommed onto this idea that this is about tab management.
Omar: It's like I have a hundred tabs open and I need this tool to help me manage tabs. When I think that's almost just a historical accident, coincidence, that the name of the project is to have a fast and that the early examples are about managing tabs because that was not my intent when I started and that's not really my long-term, I mean, it's certainly part of the system, but it is not really the things that excited me the most about it.
Henry: Right. Maybe that was like the simplest example you could think of. People latch onto that. You were going from more of like the whole analogy of this is something that we use a lot, and then this other thing, FS is something that a lot of people understand and how to match those two metaphors.
Omar: And I mean, I started this like four years ago, and I had like gone through a number of different designs for it when I've had time. The original title was ChromeFS. And I wanted to replace the Chrome because I didn't want to have the trademark in the title. But I don't know why I didn't go with BrowserFS.
Omar: But it is very much this idea of like your browser is this weird mini operating system. And then your real operating system has all these tools. How do we kind of bring the browser out? And tab, I guess, is just the most concrete thing in your browser, and so that got promoted to be the title.
Omar: Maybe part of it is also the browser extension APIs. If you go look at the Chrome extension API, the tab APIs are like pretty prominently placed and it's easy to understand what they do. So those were some of the first examples that I started writing. And so maybe that kind of accidentally dominated the presentation of the extension.
Omar: Right. So maybe it's unintentionally a good presentation. I think when you have a demo like this, like there's a lot of usefulness in being kind of conservative in what the demo does, where it's like something that people recognize as something useful.
Omar: I was thinking about this cause I was looking out some of the comments. Some people were like, well, why doesn't it use SQL or why didn't you come up with some more radical concept than just turning it into files? Files are a limited interface.
Omar: And I honestly think that.. I could have made it like a SQL Lite thing or whatever, but I think if I had done that, it would've gotten much less uptake, because I think fewer people know SQL. In some sense, the conservatism is part of why the demo is so compelling to a broader public. And then over time, hopefully, I can nudge people towards something a little bit more cutting edge.
Omar: Yeah, that's a good point. It's like you have this very concrete, like screenshot of these icons. And that's like the banner of the project is just these three finder icons. And it's like, if I made an SQL thing.. There is no equivalent of that for SQL where it's like, everybody recognizes what it is. And everybody can tell, Oh, this is files.
Omar: Yeah. Maybe if it was a spreadsheet or something, then you could do that, but for SQL it's much more kind of abstract. That kind of visual detail matters a lot. Or like the video where I'm like going through the different files in Finder.
Henry: Yeah. That's something that people are opening up every day and they recognize it, even if you're not a programmer, right. I think that's cool where there are people that might not even understand FS, but then they can see the value.. They see that that's powerful.
Omar: There were definitely people who were like, I don't know how to install this, but it looks cool. And I think they like understand that at some level, which certainly wouldn't be true if it was SQL.
Omar: Yeah. That's one framing that I think is pretty compelling, but I don't have any good examples for it yet. Unless you count the tab things. If you were really masochistic about writing an extension to close all your stack overflow tabs.
Omar: It's interesting cause it's like very much a different way of thinking about programming your computer. And it's sort of in line with some of the Dynamicland stuff, where you just sketch something out and that's a program. And it can like talk to all of this other stuff that you already have in your environment. In terms of really lightweight programming, in terms of having this space, the file system or the real world, where you have all these operations that you already know, you can just kind of reuse them now applied to new stuff.
- a lot of the difficulty of making an extension that I had in mind isn't these Web content issues; it's stuff like, you have to write it as these 3 separate scripts that communicate asynchronously, and you need weird manifest file, and you need to manually import your extension - tweet
I think that the browsers assume that your extension is a Product and you won't mind doing a lot of bureaucracy to distribute it because it's amortized over the scale of your product 😕 - tweet
like Android and iOS suggest that the average program is a substantial app built over a few months, where the packaging complexity doesn't add much to the dev time. they don't imagine that you would make a little script in 20 minutes to play with an idea - tweet
Omar: Clearly they're not thinking the same way you would if you were making a Python script or a shell script or something. They're thinking when you make an extension, it's an undertaking. It's very similar to trying to make an iPhone app or an Android app, where it's like, you have to make a project. You have to open it in this IDE and there's all this stuff around it. Even if you only want to do something very simple,
Omar: Yeah. And this is related to what we talked about in the last podcast, it shows that they're optimizing for people who are making a certain kind of thing, right? Facebook is making their messenger app or their messenger website, so that's going to be a huge app. So it doesn't matter if there's all this boilerplate around it cause it's still going to be a small percentage of this giant app that they're making. If I'm making like some one file thing and I need all this boiler plate, you know, the boilerplate dominates the actual application.
Weil man sich danach nicht mehr mit 1000 Extensions herumärgert, die 95% dessen machen, was man braucht, sondern sich stattdessen einfach einen Einzeiler schreibt! ^^ - tweet
Omar: One reply to the tweet that I really liked. I think it was in German, so I used the little Twitter translate thing. There were two people. One was like, this is really cool, but what's the point of it. And then the friend who replied to them, was like, well, now you can get rid of 95% of your extensions and just have these little scripts and stuff.
Omar: And I think that's definitely something that I want to push toward. I think that's like a really cool vision of what you could use this for. Rather than have 10 of these super complicated extensions with a ton of features where you don't understand them, you just have this TabFS, and then you just kind of program it from the outside to do whatever minimal set of functions that you actually need.
Omar: Yeah. Like there's some point where the overhead is bigger than the costs of just doing it yourself. There's like also an interesting emotional component to this question of should I use a library versus should I implement it myself?
Omar: I was just talking to somebody about this. I think in a lot of cases, implementing it yourself is actually kind of more fun. It may take more time, may take less time. But when you implement it yourself, you're actually programming and you're using tools that you understand.
Omar: Whereas when you use a library often, you have to figure out what it's doing, read the documentation, see if you can configure it in the right way, which I think is actually a very, very different feeling from programming a system that you really understand by yourself.
Henry: right. And I guess we got used to this like glue mindset of like taking things and putting them together. Maybe you feel less like agency because even though it's all open source and you could change everything, you feel like you don't have as much control. The trade-off is at what level is it worth doing it yourself.
Omar: Right. I mean, it depends on the actual domain, but I always feel like I'm usually okay with like having one or two really big dependencies where I'm like intentionally attaching myself to this thing, but lots of people use it. It's pretty much standalone.
Omar: It's interesting in the case of TabFS, because part of the reason that it took me a few years to really finish this project is that I spent a while playing with different frameworks and different languages. There was a file system that was written in go. And then there was a browser extension that was written in TypeScript with Webpack and all this other stuff. And then over time, I just got more and more fed up with the dependencies and with like trying to write wrappers so that TypeScript would accept the weird things I was doing. All of these things that are pretty much incidental to the thing that I'm actually trying to do.
Henry: I wonder if there's like this progression of starting with as many dependencies as possible and then slowly getting rid of all of them until there's only like one or two left out of frustration.
I have a lot of problems with open source as-is as a solution to this -- I think it's hugely more difficult and takes a lot more willpower to fork a library or send a pull request than to change something in your own code. you really have to go out of your way - tweet
Omar: I mean, it's like, especially if you find that the dependency isn't quite right, forking that dependency and changing it.. It's almost harder to just get rid of a right. You have to do basically the same amount of work.
Omar: Right. There's this aesthetic element to it, right? Where at least I always am like a little bit uncomfortable when I have a file I don't really need or dependency I don't really need it. So it becomes this compulsion to try and root them out, like cleaning your room or something.
Henry: Yeah. Either you have the habit or you do notice everything around you is getting worse and worse, but then there's a point where you're like, okay, I'll clean it. But most of the time it's messy.
Omar: right, right, Right. That's an interesting part of this is that this is a project that I basically was working on for a few years, you know, very much on and off, obviously. But it was like basically like in my head. And so is that part of why it's turned out the way it has? Where it has very few dependencies and it's just these two files, because it was like, there is no division of labor between different people. And it has this very clear kind of, I can drive it to have the aesthetic that I want.
Omar: Yeah, that was a really nice comment. Yeah. I answered some questions for someone's newsletter about TabFS, and one of the questions was how do you distinguish good project ideas from bad project ideas? And this was part of my answer, is that I think a good project idea comes out of some kind of personal history or personal relationship that you have with the concepts or with the system. Like it's something that not anybody could just come up with and try.
Henry: You shared with me earlier, like what you were working on and then you ended up just posting it. And so I guess you felt, it was okay to not need what you considered 1.0. That goes back to whether the idea came across and you didn't need it to be like a huge thing that everyone depended on.
Omar: Yeah. So I posted this on new year's Eve. And the reason I posted it on new year's Eve was I kind of looked at what I had done, and half the page is still to do is, but I was like, okay, I can just leave all these and just post it, so it was done this year. And I think that was the right move. I think people pretty much got the message about what this thing is. Maybe not to the extent I wanted, but it'd be hard to imagine more people seeing it than ended up seeing it. Yeah, I think there's a spectrum where there were earlier versions where I didn't have the examples up, or I didn't have the pictures, or I didn't have some of the functionality that powers the examples where I think those would not have been good to post. So I think it was the right time.
Omar: Yeah. Yeah. And I think that that was important. And it's also because of the way. Like, if you look at the page, actually it has this gray background. It has this like kinda janky font. And that was actually completely intentional, because I changed the font and I changed the background from all the other pages on my website, because when I was writing it, I was like, I didn't want to have this nice looking font or this white background, because it makes it feel like I want to be writing in full sentences. It makes it feel like I want it to be a finished page. So I intentionally kind of made it look rougher so that I would feel more comfortable leaving all these TODOs in and kind of just jotting things down.
Omar: Yeah. Well originally I think I was using the GitHub readme, and then I moved it to my website and I was like, this looks too, this looks like it would have two high a standard, so I had to step it down. I'm kind of surprised that there's not more open source projects that take this kind of approach.
Omar: Maybe I'm just not paying enough attention. Where you just like have this long page. You intentionally say that a lot of stuff isn't done. Because to me that's one of the big advantages of this being an open source project instead of like a product or something. Like I could not make this a product without like several months of work. But if it's an open source project, I can kind of just punt on a lot of these things and hope that people will get the idea.
Henry: Right. I'm just speculating, like a lot of open source now feels like it has to be a thing as well. Even though it started off being you put things on your resume, that kind of feels like this. But the purpose of that is also for the resume, not for just putting something out there.
Omar: Yeah. I mean, you also see that with, this is a bit of a tangent, but you see that with people complain about this with security vulnerabilities now to, is this culture of getting a domain, getting a logo. It's sort of interesting how these things develop.
Omar: And also, like, I think part of the reason that it made so much sense to release this early is it was never clear to me what a 1.0, would be. It's released early in the sense that there's a lot of stuff that is listed on the page that's not done. But like if I had just deleted all that stuff from the page, then I guess it would be done, right. It's not like there's like some kind of spec that I'm trying to meet.
Henry: Yeah, exactly. What is a 1.0 anyway? The only reason why it's a 1.0 is because you decided at one point, it's 1.0. Even though in reality there's no difference. It's just like a arbitrary distinction.
Omar: Another interesting thing is that because it's open source and because of the audience that it's reached, it provides this sort of comfort to me. The people who are looking at this have the kind of technical sophistication where they can deal with hiccups in the installation, hiccups in the thing running. I don't feel like I need to make it a super smooth path. And so obviously that's like a particular audience and that's excluding a lot of people who maybe would find this useful, but from my end in terms of not having to work a lot on polish, I found that and still find that really reassuring.
Omar: Yeah. And this is getting at another topic in this meta area. Like I've gotten some really phenomenal pull requests from people where they're kind of going through things in the implementation where I'd left that thing to finish up later or to fix up later. And then they basically just go fix it all and then submit the pull request.
Henry: That's awesome. Wow. Speaking to the whole architecture again, I think you mentioned like you didn't document too much, but given the fact that it's just one file for a bunch of stuff, it was pretty, relatively simple for people.
Omar: Yeah, and this is also something that we talked about a bit at dynamic land. I think documentation serves a really important function of getting people familiarized with what they can do with the system. But how can you achieve that function by getting people to look at the source code instead. And maybe augment the source code with little hints or comments. It's like going to stay authoritative if you're just looking at the actual source code. It's less work for the implementer. And so in so far as I want more documentation, I really want to push for that to be the form where we have kind of a linear programming model. You're actually looking at some kind of view on the source code and that's how it's documented.
Henry: Yeah. I guess even thinking about like how many people engage with the project. How many people ended up actually attempting to install it, let alone look at the code, let alone try to like do something with it right?
Omar: Yeah. I wonder if there's like something I could do where like to install it, you have to make some kind of change to the source code. Kind of force people to really dive in. This was something that we sometimes try to do at Dynamicland when people were visiting was we try to get you to, you know, write your name in a little program that you put it down, it would display your name.
Omar: And that I think, especially for people who are maybe less comfortable, that kind of breaks this emotional barrier of like the text programming system is intimidating. And I think that's true even for programmers with, open source projects that they're using. A lot of the time, people won't look at the source code? It's not an expected thing that you do.
Henry: It would be nice if it was like more of an instinct that you would turn to that first, rather than turn to the issues. I've seen people talk about how in open-source we need not just onboarding, but a way of deep diving into code. Maybe you mentioned people putting one in to put like a trace into the GitHub repo or just a program that you run that goes through what things are happening.
Omar: Yeah, this project is maybe in a good position where that would be compelling because you can imagine some kind of trace or introduction where like you have your actual tabs open. And so it can do something where your data is actually flowing through it. That's something that I think people really find cool and a lot of the draw to actually installing this thing is this kind of moment when you see your tabs as files.
Omar: Yeah. I, I want to do more of that. This would be a cool area to do some stuff in where you can like hop between your browser world and your graphical file Explorer world. And there's links you can click that go from one to the other. Because that's stuff that when you think about it, it's kind of obvious, but nobody really does it. I think partly because of the communications overhead of like, just implementing all this stuff. But with the file system, it's really easy.
Omar: It's also gets at some of the stuff from Acme Plan 9 editor. It sort of provided these hypertext system where if you had a text file and it had the name of another file in it, you could click on that and it would hop you to that file. Or you could put a line number after that and you could hop to that line number. So you could kind of build this hypertext network of stuff you were working on just in the plain text.
Omar: Yeah, I think that this is taking some of the ideas and trying to modernize them. Well, I mean, everything is a file. That's a phrase that goes back to the original Unix. Today, even if you take like an operating systems class, like I TA'd operating systems in college at Stanford.
Omar: Like everything is file is something that people sort of just like mumble. It's like part of history. It's like part of why Unix won. It's not something that I think people actually like often really take seriously as like, Oh, I have all this stuff on my computer. I have all these browser tabs. How can they be files? And so part of the kind of deep drive of this project is to actually take that mantra seriously and turn like modern concepts on your computer into files.
Omar: Like no new concepts. I mean, yeah. Like your Unix processor files and your sockets are kind of like files. But you know, your Twitter users are not files, your posts on your Facebook feed aren't files. And I think pushing for more of that, I mean, it's kind of like what we talked about with regard to freshness and scripture in the last podcast is like taking these ideas that people now just kind of mouth and really reevaluating them and reapplying them.
Omar: Yeah. And I think it's been fruitful doing that with this. So Acme is this text editor that's sort of like the Emacs of Plan 9. It's a text editor that's built into the operating system. And the way that you extend it is that it provides this file system. And you can like write a plugin for Acme, basically that just manipulates this file system. So you can write a plugin basically in any programming language, because all programming languages essentially can operate on files. And so that was one of the ingredients that went into thinking about how to do a browser file system. Is this idea of like, you can write a plugin in any language. And the plugin API is not an API at all. It's actually this synthetic file system. Extensions
Omar: Yeah, there's like a lot of different directions that it could go in there. There's a direction of like, what stuff do people want to do on top? And I think there's already a lot of stuff you can do on top.
Omar: I've seen a couple of things that other people have done. There's this one that I linked from the page where somebody can scrape out what song is playing on YouTube music. Now you just have access to that through the file system. And then there's also expanding the sort of interface with the browser so that you can get like the source code of pages, so that you can manipulate stuff from your terminal.
Henry: Yeah. I saw a PR that made an API for textareas.
Omar: There are extensions that do just that specific thing, right? Like where you can use vim to edit text areas. So you can write email in Gmail or you can use Emacs to edit text area. Like I've seen those and that's a whole extension to do this pull requests that's like five lines of code. So I think there is a real use for it. And somebody who had a blog post about TabFS mentioned that as one of the first things they wanted.
Omar: Yeah. We talked a little bit about it already. I've gotten some great pull requests. A lot of good issue reports. Well, it's funny how many of the poll requests and issues have been kind of either on installation? Like I can't quite install this on MacOS I can't quite install this on Linux. Or I want to port to Safari. I want a port to Firefox. Or implementation stuff, fixing bugs where I didn't write some C code properly, adding this multithreading thing. Rather than really pushing what I would see as the kind of core really interesting stuff, which is how do we expand the interface with the browser? That's where a lot of my attention I want to go. And so I wonder if I haven't documented that part enough, or if I need to have more structures to support that. Or maybe people just, maybe people just don't have new ideas about what to do there.
Omar: This has been like stewing in my head for a few years, so it's like, I have maybe an advantage over a lot of people. And the other thing that I wanted to say about response from the community is because of the way that the launch went, where it was immediately like number one on hacker news for like full day and a half. It was like really, really popular. And then also mentioned in a bunch of other places. It immediately went from basically like this project where I was the only one on the project. It was a private project that I've never linked anybody to. To having like thousands of stars and like dozens of issue reports and pull requests or something. So it was this very like accelerated timeline for open source, where, like immediately I was suddenly the maintainer of this project with like a bunch of people sending me stuff.
Omar: But I think that's like that in some ways makes a lot of the choices a lot clearer than when you have this kind of boiling frog situation where your project slowly grows and then over time, after a few months or a year you find that you're maintaining its thing. Where now to me, it's like immediately clear that I need to like figure out, how am I going to spend my time with us? What kind of commitments do I want to make?
Henry: Thanks so much for listening to this episode of Hope in Source. To continue the conversation, you can find me on Twitter at left underscore pad. If you'd like to check out the transcript with links and references, please visit hopeinsource.com.