Andrew: Hello, welcome to the dev tools, FM podcast. This is a podcast about developer tools and the people who make them I'm Andrew. And this is my co-host Justin.
Justin: Hey everyone. Today we're very excited to have Orta Therox joining us. Orta and I work together at Artsy and... yeah.
Such a pleasure to have you on man. Could you tell our listeners a little bit about yourself?
Introductions [00:00:29]
Orta: Sure I'm, you've said my name a few times, so I'm Orta Therox just in case you've missed that for the third time. But my background is you know, I started as a computer scientist, like a lot of us and started making more and more first games. And then I realized that tooling was actually something that was more interesting to me.
Eventually I started building apps for the Mac and then apps for iOS. I'd got hired into a place called Artsy where I managed to help create a sort of culture called open-source by default. From that I contributed to almost every major iOS open-source project. And then eventually, Artsy moved to react native.
So I got involved in the JavaScript ecosystem as a part of trying to consolidate our tooling across web and iOS. And that eventually led to me feeling like there was gaps in how TypeScript the programming language was pitching itself to the world. And so for the last two years I've been working on TypeScript programming language and its documentation and how it interacts with the ecosystem and all that sort of make life better.
The TypeScript users as a community,
Andrew: Did you seek TypeScript out or it was. it like you got contacted by your recruiter and you're like, "oh, that, that might work."
Orta: No, this is as GitHub as you can get. They had a GitHub issue that says we are hiring and what they were expecting was a compiler engineer. But what I pitched was what you think of my job, which is, I went and fixed all the documentation I went in and fixed the playground I made it easy to contribute to these things made it possible to be localized, helped improve, definitely typed a lot. blah, blah, blah, blah
so a lot of ecosystem, I described it to the team as being like, " TypeScript is this castle and that like this village around it. And so my goal is to improve the village around it in order to make, people that want to work on the castle to be able to keep working and focusing on that.
So that was obviously a successful pitch. And I've got most of that stuff done now. Super happy!
Open Source Design [00:02:43]
Justin: Yeah, you've been doing a lot of great work there. It's been a joy to watch it evolve. Also one of the things that you do that I really love is you bring this design sense to the tools and to the ecosystems that you work with. Folks might not be aware, but you've had a huge role and helping design a lot of tools that people might use.
So what you help with prettier, with jest, with relay
Orta: GraphQL.
Justin: many more. GraphQL.
Orta: Yeah,
I've got to redesign for Babel in the works somewhere. Oh, the new logo, the logo that I have for it is absolute gold. I've just, haven't managed to get it out in the public yet. A bit of Docusaurus for us too. I've got some, I've got some design explorations for that as well. After my first job back then, supposed to be way over 10 years ago now, I came out of that feeling like, I was not an entirely independent programmer.
I still had to have a lot of reliance on designers and project managers to be able to do whatever I wanted. And so I lucked out because the job was collapsing because the company was like fell in on itself. And at the exact same time, I got a small inheritance from an auntie who I never had met that died and use that to go to a a design school.
And so I then reuse those skills is you know, I'm definitely not designed a quality. Like you probably wouldn't hire me to be a full-time designer, a company, but I'm definitely so far ahead of the average developer, that those skills are just super valuable in all these different places.
Andrew: Yeah, it's something I try to practice too. Like I'm not, I'm by no means am I a designer, but I try to make my documentation really pretty, and it's a journey where I started is ugly as hell and where I'm at is probably still ugly as hell, but I'm a little bit better than I was yesterday.
Orta: yeah. Yeah. I've actually wondered about trying to productize the idea of me talking through the process of designing some of these sort of things. I've just finished up a design of this documentation engine that I built for typescripts website that allows you to have hover on code samples and have TypeScript compiler really backup their code samples, say what they say, they say and designing the website to describe it creating the branding for this sort of mini library.
It's a lot of work on a lot of people are very interested in it. And I think trying to find a way to not just do a series of Twitch streams, but to productively be like here is designed one here is designed two here's designed three. Cause sometimes it just looks like magic, but realistically it's just a lot of graft to just trying to iterate again and again on an idea or until you hit it, it took me three full designs to eventually hit the design that I was happy with.
And like each one, I was like, this is somewhere in this, I just can't find it yet. It's like trying to find the right abstraction can be hard, but with design it's also the same thing. It's tricky.
Andrew: You alluded to the project you're currently working on what inspired you to start like focus on that so hard and go such a weird direction with the the design. If our viewers probably haven't seen it, but it like is a medieval inspired doc site? That's what I'm getting out of it,
Orta: Yeah.
Andrew: explain more.
Orta: So I see a lot of the time inspiration, you just find it by accident in this case. So this is a medieval style, like think of an old medieval style book, and then try and modernize that in your head and then try and take a lot of the sort of graphical systems that would be used by that.
And then that's basically what we're doing for people that are listening the, like for that you can actually get all of my designs for this, the public. So my original sort of design aesthetic for that was the first attempt was take this art movement that I can't actually think of the exact name of it right now, kind of expressionist.
I knew that the code samples would conceptually quite boring, right? Like the idea of just looking through the same ish code samples that have a tiny little bit different, because I'm trying to describe, what happens when you include this compiler option. This is this one is that it's like intrinsically a little bit boring.
So I want it to the area around it, the sort of surrounding to be very colorful and interesting and eye-catching. Every single site like this, I try to design should always have a strong hook.
If you've seen Jest's website, Jest's websites hook is the idea of these intractable cards. That act a lot like a testing system. So you can rerun the cards.
Prettier has the logo is actually not formatted and then when you go to the website, it falls back to the logo to fit into space, which, again, plays with the metaphors of what prettier is.
Relay has a similar one where it has the logo and like the code actually flows around the entire system.
I needed something like that, but to work around the problem of the thing that you're looking at is quite mundane. And yes, I can show it in different colors, but that's not very interesting. So what I needed was a way to frame the code samples and an interesting sort of design aesthetic. My first attempt at that was very expressionistic, lots of colors, lots of abstract shapes.
And then my second attempt at that was to look at this book and I took a lot of the ideas from this book very literally. And so it really had, it had like gradients emulate, what pages look like. It had very like similar font styles and very similar rules. And then it turned out that, like that actually, it didn't feel very good.
Once I got closer and closer to it, like it's a little bit like the closer you get to try and represent something in reality, the closer you actually get to see how far away it is kind of uncanny valley almost. So I actually pulled back quite a lot, as I said what am I actually trying to do with this?
And then took the, colors tried to modernize. Those took the Paul. He tried to modernize it, but make it feel like it's still is old school. And then using those sort of metaphors recreate and redesign the entire thing. So it's still built pages and chapters and things like that, but it's built to flow in as though it was a webpage. And instead of flowing more like an old school book.
My wife was going for a design course right now. And I was trying to explain to her that like skeuomorphism, to me is one of the most interesting, like design aesthetics in part, because you get the cheap way to explain something, because you can say, it's a bit like this.
And in the process of doing that, then I, you know, it's like, you know, it's a book, so we'll have chapters and your pages could maybe move across. And the structure of how you read these things can be done in an interesting way. But once I started like actually playing with it it really started to feel like I was stretching the metaphor too far.
And that's, part of the problem with skeuomorphism is that you can get a bit too close to the sun quite easily. And then you end up going back too far, which is my general opinion on modern aesthetics. I'm at a neat halfway point where it feels old school, but it also feels it was built today.
Who'd have thought we'd be talking about design so much on the DevTools, but I think actually it's a good angle. Like there isn't enough people doing serious design work in an open-source. That's a really great Twitter feed called design and open-source. And they keep track of interesting work done in the space and provide a sort of central community for people trying to do more of it.
So if people are interested, you should a search for that on the internet.
Andrew: Yeah, we'll definitely include that in the show notes.
Justin: Yeah, for sure. I think it's an apt sort of conversation generally though, because building tools is it's an exploration in user experience or developer experience or whatever you're trying to solve a problem. And a lot of times how you present mechanisms for solving that problem are very important.
It's like the interfaces or the abstractions that you choose or how you represent your API or whatever. These are all design decisions. And in the same way as picking your visual hook or your visual metaphor to help people build a mental model of what this thing is. And it's all related
Orta: I completely agree! For example, the design aesthetic for Danger is very much like bang in your face. Like this thing is here to actually stop you a little bit. And so it needs to be like actually a little bit loud and in a way that I probably wouldn't design for other types of software, but like design is how I got my first, like real chomps in large open-source.
I contributed a redesigned to CocoaPods. Yeah, that must've been eight, nine years ago after feeling frustrated on building sort of a CocoaPods related web project. I'm feeling like I was constrained in my design and trying to conform to the sort of feel of the CocoaPods designs.
And so I sort of pitched to the team then, that's to some extent, how me an Eloy another ex Artsy person who also worked with me at Microsoft like I said to him I think I can redesign CocoaPods elegantly, and he trusted me with it. And that ended up becoming the sort of design foundations that have lasted for eight, nine years now.
I don't think anyone's itching to get it redesigned. It still looks like it was built today.
Andrew: I think that's an area not many people think you could actually get into contributing design to an open-source project. Nobody's really putting out like feelers for that in their GitHub issues, but I'm sure there's a lot of people that would be open to a little bit of design influence.
Orta: the ones that people never really think of either is actually just having like. It's quite often that I act almost as a mentor to open-source projects, but not necessarily do any of the work. I kind of did that for Svelte like I, I came in and offered some advice and provided some tooling. So I just helped build CI and all these other things to say how TypeScript to this felt should look, gave her a very rough prototype.
And the moment I did that, two or three people took over my work instantly. And all I have to do is just wrap up some of the details, try and provide a long longterm vision and get all of them on board. And since then, I've never, I tend to occasional maintainer chat meetings and just act as like someone that's done this before and just provide some useful advice.
It's a very like weird contribution. Cause there's no GitHub contribution graph for that. But you know it adds to the ecosystem. So that's why I do it.
Building Pluggable Platforms [00:12:38]
Justin: I want to go back to something that you talked about earlier. You'd briefly mentioned Danger and people listening to this might not know exactly what Danger is, but you also have a related project called peril. These are tools that Artsy used internally for awhile, and were always a really like conceptually interesting automation abstraction. So do you want to talk a little bit about those tools and what they are and what your inspiration was and how you think about them these days?
Orta: At large-scale open-source, there is this sort of fundamental problem that it's almost the same in every single type of community, which is the, 1% of the people involved in it actually contribute maybe 10% will do a drive by it. And then 90% of any community will just passively consume.
For Cocapods that meant that there was roughly five to 10 of us, occasionally contributing a useful sense. And then, hundreds of thousands to maybe millions of iOS developers using this dependency manager every day. And that is a blocking part of their day-to-day build cycle.
And so what ended up happening is we would get a large amount of like we're pretty low quality issues and pull requests from people. The same thing was happening in a sort of adjacent tool called fast lane. And this was made worse by the sort of problem that these tools were not built in the same language and ecosystem as the developers were using every day.
So think about it today in our JavaScript parlance, we were building it in rust and everyone was writing in JavaScript and they would come in and try and help out, but not necessarily do a great job at that. So I started thinking like, what is a better abstraction to help add new sort of rules, the not integration tests, but live at a higher level of abstraction, but are at pull request level.
And that gave us sort of the ability to be like, "Hey, you need to add a change log entry. Hey, if this file changes, then you need to change this file." A lot of people hadn't even got used to the idea of lock files at this point. So, "Hey, you've changed the dependency. You need to also run this to make sure that the lock file is updated at the same way."
And so Danger kind of came out of this, like desire to really, first of all, deal with the scale of incoming contributions to a project with very few maintainers that know we're just trying to do it in their spare time. Once I actually started getting that up and rolling, it turned out that once we started dogfooding it inside artsy, it became very different use cases inside the company than it was at large scale open-source.
And so I started to reframe Danger as being like a system that's really good for institution, the cultural rules of your code bases and, each individual code based generally, especially if you have a team working on it full time, they will definitely have all these implicit cultural rules.
Don't edit this file. If you do it, this file, you may need to edit this text document. There's a million of them. And eventually we found out that Danger could provide sort of low level abstractions that we could have in each individual code base that could show that those rules could be agreed upon by the team.
And once they were agreed to call by the team, then we could actually put them in place with code. And when the team agreed to do a change like entry on every change you either have a way to automate that or you have one person on the team who becomes the, you know, the, the bad guy saying, Hey, we all agreed to do changelog entries, and you just forgotten the last five PRs. Person that created the PR and person that merged the PR.
Please keep on top of that. Uh, and nobody really wants to be there person and so Danger starts to take their responsibility away. So you you find ways to frame the messaging in Danger to be nice about it. At the end of the day you, as a collective agreed to do this thing and so Danger can help you do that thing.
And what was interesting about Danger and what's still to this day is very different to almost all of the other types of systems that do this, is that Danger expects you to do the work like expects the rules to be custom on a per project basis. And I regularly get people asking, can I make a preset into Danger that does all these different things.
And I continually deny that. And this is part of my goals of being able to maintain these types of projects over very, very long time periods. Danger is somewhere on the range of eight years old, maybe at this point? There's five separate languages and it's maintained more or less just by me.
So the goal here is to have this tiny core. The no one else, uh, like I'm pretty dictatorial about but then by doing that and by building a plugin system that allows anybody to write any type of rule, anything themselves like just to give away the entire system it allows me to keep the incoming PRs and issues low because most of the logic lives user land of not necessarily, it's not up the kernel of Danger.
And so that worked out quite well. We use Danger in a bunch of different systems. It provided us a way to create new types of cultural rules and make agreements and built that in code once we were happy with it.
And it took, a few years after that to start thinking, what is the abstraction that sits above Danger? And that leads us onto the second one, which is Peril. And so if, if Danger is about trying to say one code base should act like this then Peril is about trying to say our entire organization should look like this.
A simple case is the changelog entry, like the one that I mentioned at the beginning the changelog entry is still the first thing that I thought of when I was building Danger. And it was also the first thing when I thought of, when I was building Peril. What does it look like to just automatically say, 'Hey, if this repo includes a change log entry, a change log at all, then we should just automatically check on every PR across the entire organization that, that this thing includes a this PR includes a changelog entry."
If the repo has a change log and that's part of the key. It was going from the lake. I'm now coordinating one codebase to I am orchestrating across many types of code bases. That started to work out quite interestingly on rules that could be applied across many code bases.
But where it really started to thrive as a concept was once we started to culturally accept Peril rules as being systems that anybody can contribute into inside the company. So again, Peril takes the same conceptual idea, which is that like your code, you write the code, the code has to live in use land, not necessarily live inside peril.
Peril is a generic runner of arbitrary rules by letting you evaluate JavaScript with some special globals. And basically we got Artsy to a point where like we started introducing an RFC system across the entire organization in order to account for changes to how the culture should change.
We started to systematize these things and those, the systematized rules would actually be backed up by peril. So a trivial example, that is just like something that you just, you can't really think of doing this without having these sort of systems was somebody introduced a a way to check the, who is assigned to the Monday morning standup.
So there was a sort of, we called it the big standup. Everybody gave a brief, like two seconds, a ten second intro of what they were doing, and we want it to be cycling the person who was doing that around. The system of providing notifications ahead of time telling everybody who was doing it and pinging everybody in and slack was all moved into Peril.
And it was just like three JavaScript files in a repo, which meant it went through pull requests. It was reviewed, we have tests on them. And like any other way to do that, would've required either third party services, so you could look at this as a third party service, but it would require multiple third party services or completely building this entire server that had, Cron jobs and things like that.
Today. You could probably build this and GitHub actions, but this predates GitHub actions. That meant the, you could start building these really interesting sort of. Cultural systems that codafide how you would explicitly agree to do things. And it's a really cool abstraction.
I was really happy with it... until GitHub actions came out! Then I realized I'm like, and then I couldn't really compete with, GitHub actions because they're so intrinsically linked to GitHub like the way it was working that like I felt like it wasn't necessarily going, I couldn't compete with GitHub actions, was like, I'll repeat that again.
And this has been the bane of my life for almost every single project I've ever built that was big. It was a big company decided that was a space that was also worth exploring. And couldn't like, you can't just compete with a big company in your sideline. So I work at Microsoft now where I have a big company.
so that's Peril and Danger, like taking a small cultural rule, keep abstracting, abstracting. abstracting until it became really easy. Only building the engine, and expecting everybody else to be building the, their own rules and use the land. And then moving that further and further.
This idea of what should be a common core even lives today. The two slash system we were talking about with the cute documentation and that has a really tight core, but it still expects you to set up your own JavaScript and CSS. And, there's lots of other all in one bundled systems that will get you syntax highlighting and do all this stuff, but the don't require you to do that sort of thing.
But like my belief system is, or a parts that are best handled by like individuals on a per project basis. And there are parts that are best held like inside a strong, small kernel and that's how I can maintain. That's all I can say. Like I expect to be maintaining this for maybe five to 10 years just on my own, even if I don't work on TypeScript.
That's how, that's the bit, that's the hard bit trying to make sure it's small enough that I can add it to the list of existing things I maintain on scale in a way that like doesn't eat my time too much.
Andrew: that's a big part of open-source is choosing what should be merged. And it's a very hard line to walk. You don't feel the best sometimes when you're like, ah, I don't think there should be here. Uh, PR closed.
Orta: Yeah. And that's answer for this. I have the, I have on every big repo that I think people will be contributing to for a very long time is to have a vision dot MD file. And it's there to tell you whether something will get accepted or not. And whether it fits with my vision cause I'll allow for some vision changes over time, but there's a core crux of every project and if an evolves too far, then you either become too popular and you start to need a lot of people being involved or to some extent it's a different project at that point.
Justin: Yeah, for sure.
Owning your Dependencies [00:23:05]
It's funny this whole conversation reminds me so much of just like how we all met, uh, because there's a lot of paths that cross. So at Artsy, and I think you mentioned this earlier Orta, there was this principle of own your dependencies. And it was, I guess it was.
And maybe you can tell us, but probably instituted as a part of this, like overall conceptual notion of open-source by default. Because when you're open-source and you have open-source dependencies then sometimes the best thing that you can do is contribute and improve those dependencies to improve your own team, but also to improve the ecosystem.
And very similar story of when Artsy discovered Auto,
Yeah, you, do you want to talk a little bit about that and that discovery and like maybe the cultural aspects that sort of drove like
Orta: Owning your dependencies came out came out of an understanding that like a lot of what we build sits on top of a people's code. And if you consider that code is not really yours, I think you'll, end up in situations where you don't understand what's going on in the application that you're building it's like the idea that, if you're a junior, don't take this advice, but if you're like, leading up to being, sort of senior and upwards, like you should be able to understand every abstraction that you introduce into your application.
And every single thing every dependency is also a liability in the same way. Even in the node ecosystem where, suddenly you found out that handlebars has a way to take down your site because of some weird parsing errors or whatever. Like to some extent, if you include handlebars, you should be able to go and maybe fix it because you know, this is part of your code base, regardless of whether you know it or not. and trying to decide where that abstraction levels stops is tricky, right?
Because you could say, I need to be able to maintain Linux because we're all running on Linux servers which is obviously, a step too far. I was talking with some of the maintainers of node and they say some of their tensions is that nobody thinks that they can contribute to node.
Right. They think that, the abstraction level of having a node application is I understand all the JavaScript in it, but I will never try and help make fixes to the node level. And TypeScript to some extent has the same problem. Like I don't know if most people could contribute to the TypeScript compiler code base, but they actually technically could, if they'd have some JavaScript knowledge The tricky thing here of all of this, it's like trying to decide what is the risk and what is the reward for taking on the dependency?
And by knowing that you can own the dependency and that you take very seriously the idea of being able to either get access to have write access to the repository, if it matters or to be able to fork it and truly, just own it yourself entirely. Artsy has tons of stories where we've looked at the dependency, said that's probably the best one of its set.
And then taking over it completely. And sometimes that's been like, we've completely taken it in a different direction the original author had. Cause they originally just thought it was going to be the small thing. Artsy came in and was like, yeah, this mapping solution. You've got like, maybe we could reapply it.
And. Boom, all these different contexts. And in those cases, you're basically taking over the entire thing. What we were trying to do here is there was a lot of tension inside Artsy around how we deploy software. And I think there still is. I like, even today, I've built like 50 different ways to deploy things, even on NPM, when you can just deploy on every commit and no one's going to complain.
The most recent one I did, you have to change the package number. If you change the package number, it will automatically update it. A previous one, I had the checks on nightlies, blah, blah, blah. You know, the systems. And we were feeling this tension on shipping too often because that would trigger all these notifications everywhere.
And so I think me and Justin sat down over lunch and ended up discussing the idea that maybe a pull request is the right abstraction for what a release could be because that tends to, collect a lot of commits into a single thing. One of the good things about having all this automation is that we could take an existing workflow and then build things on top of that.
So nobody, nothing changed for people's day-to-day work except that you now had the ability to declare whether it would be a minor or major. So every PR would automatically be declared as a, SEMVER patch and you could declare if it was upwards of that. But otherwise your entire flow would just be the exact same.
We had all this automation for the CI side, I had a rough prototype of it and then started to get a sense that this was like actually a more complicated problem than I expected it to be. I feel these same tensions with Danger all the time, because anytime you're trying to, interact with the same system that you're on whilst running inside, it ends up of all these complicated edge cases.
You never actually believe exist until you have to like actually build it. And in the process of building out, I started looking around. And found auto was being built recently. I found one called pleb, which is like, or really terrible name if you're British. And so I reached out to Andrew I believe, got a general sense of what he was doing with it, where it was going to go and said, instead of, continuing to work on what I was working on, I would turn my work around and turn that into a blog post explaining why we're going to start using Auto instead. And trying to describe Auto to the rest of the team in a way that would that makes sense fundamentally.
So not necessarily going and fixing the docs, but making a separate set of docs that could be used internally. That was also publicly available to describe the why and the, how the decision to use someone else's code instead of our own. And I think that's sometimes why, like a lot of value people can get cheaply to the open-source ecosystem, like a migration to or from stories, always great.
Especially when they provide very unique insight to maybe like the code base and the culture of the team. I think that's where a lot of the value sometimes comes from just publicly writing about your day-to-day work. I read every TypeScript migration blog post I can find both to and from in part because they provide really useful insight into what the onboarding process looks like, how you migrate to strict mode when those like, 50,000 files or whatever.
I've seen that in a lot of different, interesting ways and TypeScript reads all of them too. And we all try and figure out, is there a abstraction that TypeScript can provide that can do it? And there isn't yeah, but like we still keep reading. But. That to me is I think the value, we provided some bias by adopting Auto and taking it very seriously.
I think we might have shipped a PR or two and you just indefinitely started helping out properly for awhile, but like having the opinion that we needed to at least be able to feel like we can make contributions that will get upstreamed and that this literal block, it potentially blocking part of our day-to-day flow is maintained responsibly was just like part and parcel of trying to do open-source.
Right. As a company. Okay,
The Friends You Made Along the Way [00:29:44]
Andrew: And that's how me and Justin met. You're like, Hey, there's this other guy that works at my company. He might be able to help out too. And then we hopped on a zoom and fixed a bug and got into one of those hairy edge cases you were talking about.
Orta: Exactly! Yeah. That's the perfect sort of story for me. That's the thing that I really like about open-source, right? To me, it's about meeting all these people, understanding all these systems. It's like my opinion on Twitter, right? Like I'm at like 20,000 Twitter followers.
But the thing that I really care about is that there are sets of people that I am very interested in being able to have like simple colloquial conversation with. There are like sets of people that I would like to be following me that I would like to follow it back and that we can easily communicate because we have like very low friction to communication because we've occasionally interacted over system around smallest, irrelevant things.
And so the same thing, I think it works in open-source too. It might feel like it's not worth your time to, fork this project, do the pull requests to do all the other stuff. But when you get the surprise, like, "oh I was just thinking about you when I was making a conference and you, I think you're a really good fit for this."
And being able to have those relationships is to me, some of the most interesting parts of doing high scale community work.
Andrew: yeah, to, to me, Twitter is like the missing messenger part of GitHub. Like the two things are so inextricably tied for me. Cause like a lot of the time I'll make a pull request to some random open-source maintainers, repo and be like, "well, let's see if they have a Twitter. I want to talk to them and see what's up."
And most of the time they do. And that's the easiest way to get in contact with them. It's amazing how you can tweet at some of these larger personalities. And they'll tweet back like Justin tweeted at Nat Friedman, the CEO of GitHub and he replied within two minutes. It was crazy.
Orta: Yeah. Like Anders Hejlsberg will occasionally respond to tweets on Twitter. Okay.
Andrew: Yeah. I'd I'd say Anders is our white whale. Uh, getting on here would be like, oh my God, that'd be such a guest.
Orta: All right. I'll uh, I'll poke him about it. I don't know how often you'd be surprised. Like he does a bunch of stuff that you wouldn't expect him to do. Like during the, the, the, uh, well, the pandemic is still on. He actually goes, he spends a day, every week running the vaccines out in Seattle. Like he's just like super nice, super empathetic.
And you, if you're in Seattle, you could have had the vaccine given to you by Anders
Andrew: that's crazy.
Orta: Yeah.
Andrew: You're getting your vaccine. You look at him. You're like, wait, turbo Pascal.
Orta: Yeah. You're the C sharp guy. Yeah, totally good. I really enjoyed that idea.
These are just people, right? Like Anders is super nice low high, like approachable guy, but he's been there the gang of four, if I recall, and if he's not, then he is, we have enough in Microsoft that I've interacted to that, like they're all extremely approachable.
The problem always is just they just get so much noise, so it's hard for them to figure out what's worth replying to or whatever. But yeah. Yeah. Nice folks, everyone that I've generally interacted with, it's like most people that are trying to do this kind of work, especially dev tools like I think you need an awful lot of empathy to work in dev tools because you first need to, feel the pain yourself and then you need to.
Feel other people's pain. Once you fix a problem, that's large enough. If you want to make something work for more than just yourself, so then you need to understand how people's pain. So like
Flappy Royale [00:33:13]
Andrew: So you mentioned that you actually started in game dev, which I'm pretty surprised by, but you haven't really left game dev all too much in the dust. Recently in the past few years you came out with flappy Royal and that seemed like a super interesting project. Like what brought that to your mind and what made you really like chase after it so much?
Orta: So Flappy Royale is a game where we applied the ideas of Fortnite to the ideas of Flappy Royale. So take a really frustrating game and then try and put 99 players playing it simultaneously. It came out of like I had a month off in between jobs. I'd worked to Artsy for eight years.
I was going to go work at Microsoft. I knew I had a month but I didn't have an office now that I didn't have a Artsy to go and work from. And it turned out a very famous games designer and I go through the same dog training school. I mentioned this, that he was just like, yeah, just come work at my house.
Cause. We had the big office space that was available. And we were jamming there, and I was like, I was just throwing these ideas out. Cause I was like, I've got a month. I'd like to not ideally work on something that would be too time consuming. Then maybe give me a chance to chill out a bit. And he showed me that he had recreated flappy bird when it came out.
And while he'd spent all of his time on, was trying to get the physics right. Like the animation and the physics are the exact same as the original, all the sprites with different. And I said it'd be really interesting if you take that and put 99 players on at once. Cause this was the time period, but Fortnite was still massive.
It's still massive now, but like, you know, a royale, every game was, was still being explored to what royales meant for them. And what was tricky about this was that like, I didn't think there was any value in doing real time, 99 players on Flappy Royale. Like any idea we could have to try and figure out, how do you put 99 players on the screen?
Doesn't really work in 2d, right? Some of the best examples Mario Royale and Tetris Royale, they split your game up into, then all these different sort of Sub games across the screen, but you can't really do that with Flapper Royale. Either everything moves too much.
It would be really distracting. And I started just exploring the space just making a solid reproduction and then a friend of mine, Em Lazerwalker with she was staying at my house. And so I was like, you know what, I'm going to go work at Zach's, uh, would you like to come down? She, saw it and was just like, I know exactly how to make this work and came up with a bunch of good ideas.
And so I was like, all right. Em and me came together and said, we'll work on this full-time because both of us were going to go work at Microsoft in the same time period. We'll see if we can get it done in a month. And we managed to do it in two months, which I think is pretty good. It was this game that had millions and millions of plays over the course of like two weeks.
That was during a period where we haven't got all the ad revenue deals sorted and then by the time we had got all the ad revenue deals sorted like most of the user base decided to move on to something else. So the key here is you can explore ideas and you can get really popular, but if you haven't captured like any finance from it, then you'll just never get anywhere.
And so I keep it ticking. Like it costs me probably about $5 a month to keep Flappy Royale running. But I, at the moment I'm actually exploring like a new game. A new, very kind of complicated series of games that all interact with each other across across dailies and weeklies. Still not far enough in a solid enough to have an idea on how it is, but but it's been really cool trying to take a lot of interesting web technology and abuse it and use it as game systems. All of these, like I built multiple games and all of them use Redux as sort of game engine.
And so the entire game runs in memory. There's like a rendering layer on top that then tries to take the readouts game store and then turn that into something that you could see. And I'm finding that like very, very satisfying to work on. It's very test driven because everything's just done in memory.
And then you say like, okay, well, if you press it this time, what would that trigger instead of the store? These are very mature abstractions. So that's great dev tools as far as great writing Redux, especially, it's got a really great rerun at its documentation in the last year or two, as well as converted to TypeScript and really hammer down what the developer experience of using Redux is like, now, if you've not used it before, or you have used it before, and they're not happy with it, it's very, maybe it's very different now.
I don't know what it's like, but I've been really, really happy using it. But I do only have to answer to myself in these code bases. So, I don't have the problem with not being happy with what someone else is doing with it.
Andrew: I just got introduced. Like the first time I've ever had to professional use Redux is at Descript. And the amount of Redux code there is crazy. There's one file. That's like 3000 lines long. We use a sagas too. It's just going from just react only state to this super global state.
Or you can throw an action from anywhere is crazy. But I could see how it would pair well really well with a game.
Orta: Yeah, it does. And that's the thing again, this is always a lot of these things are like scale, right? Like a 3000 line, probably I'll say TypeScript file or the like, also is a trend for that into the type system also will slow down your code base over time. And it's just all these like subtle things that occur, but they're also part of building a big thing, right?
Like you, can't not use TypeScript realistically at these scales. If you don't, you're probably gonna be using typescripts tooling under the hood anyway, to try and get you that developer experience. And so it's a, it's like the constant battle,
which, you know, maybe we'll win.
The Future of Types in Javscript [00:38:53]
Andrew: Yeah. I think we'll be more and more tied to TypeScript. I see people argue that, "Hey, JS, which is going to add types someday!"
And I'm like, yeah, right. Like to this level? Um, probably not.
Orta: well, I mean, I wouldn't
Andrew: Oh, you think so?
Orta: yeah. It depends on the definitions, right? Will JavaScript allow for types probably will JavaScript having a static type system. No doubt it. So no one wants to put TypeScript in a web browser. No, one the TypeScript compiler in a web browser. People want to put TypeScript code in a web browser.
But all that will mean is that you'll be writing TypeScript, but and a JavaScript-y way maybe. Especially now that Flow has totally given up on trying to do open-source and has also given up on the idea of trying to retain pure JavaScript compatibility. Which means basically this playing TypeScript is more or less the only type system that exists for JavaScript theres hegel, but hegel relies on TypeScript definitions.
They mostly copied the syntax for TypeScript and then use DTS files. So effectively at this point, it's like, how can you get those to run in javaScript? Is a really legitimate question that I'm pretty sure a bunch of people are asking.
Andrew: And we're bound to see a bunch of TypeScript compilers written in rust in the next few years.
Orta: Well, there's one, there's one with bell being built and go, we'll see if it can, the people that make SWC you probably know it from that's the thing that powers vite's JavaScript, TypeScript, converter that the offer of that. Oh, and the one that's the Deno, that's the one that Deno uses That's trying to, well, Deno have no interest in playing the the type system inside rust, but they're very interested in there is someone very interested in trying to do it, honestly. I think it's that's tilting at windmills that for sure, I think you can have multiple copies of something like multiple copies of Ruby is trivial because you're only building the runtime, just like multiple JavaScript engines is
trivial, but like the TypeScript code base is absolutely wild because there's just so many edge cases from 10 years worth of stuff that you would just have to copy. And you would be on a new code base if you're using this type checker maybe, but you probably aren't right. People will be like, I'm going to switch to this for speed.
And then you find out that actually. Uh, it's not catching a lot of the things that the editor is catching. And then you're suddenly like, oh, maybe we're going to have to use TypeScript again, back put down CI. Is there value in having a tool that can get you some of those errors quicker?
Yeah. Maybe like you could maybe move to the editor as well. But I know without TypeScript team doing it, I can't imagine that working. I don't think Anders wants to have to write another language to, to write TypeScript in.
Justin: I think my sort of perception of the big opportunity in this space is it's sort of, what's already happening. It's, it's less of like type checking, but it's more of like, we'll give you something that can interpret TypeScript and just convert it to the JavaScript equivalent. Basically just stripping out the types and converting it down because that's where a lot of opportunity is like you use TypeScript to type check your code, and then, maybe you have a service worker or some WebAssembly thing that just like automatically intercepts your request to this TypeScript file and strips it all out. about like transpilation as a build time thing. Those things started becoming really interesting and powerful ideas.
Orta: Yeah, I think a lot of this move to use, go and rust and JavaScript projects reminds me a lot of when we started using React Native Artsy. The metaphors that we were using, actually, whether we use JavaScript to coordinate our native code. And so we could basically keep the same like quality experience that we were having, but basically improve the developer experience drastically by reusing our existing native code for doing the hard things and then using JavaScript for doing the easy things. And the JavaScript stuff would coordinate all this code under the hood. And some code didn't need JavaScript. Some code didn't need the native stuff, but like being able to jump between the two, depending on what context was important was what really got us super productive on React Native and what sold us as that as a dependency that we needed to own, like we had to ship multiple PRs to React Native.
I went to multiple meetings at Facebook to try and make sure that like we were copacetic. Cause even then Artsy was having a completely different way to build React Native than the entire rest of the community. It took two or three years after we supported, CocoaPods in React Native for that to become the default way that everyone does it.
Tooltips [00:43:21]
Justin: Yeah. All right. So let's go ahead and start wrapping up. Maybe we want to do our tooltips.
Uh,
Andrew: My tool it's another tool from the same company that I mentioned last week that makes clean shot. This is called pixel snap and it's like a super good pixel measuring tool. I've used a lot of pixel measuring tools on the web. There's lots of good Chrome extensions that do the same exact thing.
But the cool thing about this one is it works on any element on your screen. So like it could be a native app. It could be the iOS simulator running a webpage, it can be anything, and you can measure the pixels. And as the screenshot on their website shows, you can wrap it around elements and get a box and then measure between the elements you can set horizontal vertical measures.
It's very useful when doing UI development and you're developing on a place where you can't use Chrome extensions. So I would highly recommend it again. It's another paid app, but I believe if you're making a really good app that really solves the problem. Well, it's worth paying for some of them.
Okay.
Orta: this really reminds me of a tool I used to love that lets you like, so I know how this is built. This is using the accessibility manager in the Mac and another great tool that acts like this, and I'm not counting this as my tool tips, but it was called shortcats. So like a shortcut, but it was a cat.
And it would allow you to just almost have VIM modes, like for every single possible clickable item on your screen. So you just press this button. It would show a little clickable label everywhere you just type in like a AF on your mouse would instantly move across the screen and just click it instantly.
And you could just get away with never using a mouse because everything was like accessible via the accessibility APIs. Loved it. Super cool that I really enjoy people exploring those APIs. That's a cool, I, I might get this.
Andrew: it's crazy how many people abuse the accessibility API to do cool things like that. I think next week we're going to have on the Fig guys, and they're just doing weird stuff with the accessibility API.
Justin: yeah.
Orta: that's what they're there for. Right? That sort of thing. So not available in the sandbox iOS-y types of, of tools and that's in part why you'll never be able to be as productive in them as you can be in the desktop operating systems.
Justin: yep. Cool. So my tool tip of the day is actually this really interesting, open-source project called MRM. The tagline is essentially code mods for your configuration. It's really, really fascinating. So let's say you wanted to add Jest in a preexisting project, you could type MRM like NPX MRM jest.
It would go through and add the configuration files that you're missing, modified the ones that already exist and essentially apply this codemod to your project to build, add something in used it for the first time. This weekend was awesome. Yeah, it's great. If you need to add something to your code base, then this is a really compelling way to do that.
I was thinking like, while I was doing this, I was like, oh, Definitely should build a plugin for auto to do this. Cause there's, I can't tell you how many times that I've forgotten public access
or something to my package dot json and I'm adding Auto . So it's this kind of thing is great.
Andrew: Yeah, I built one of these internally Intuit that I called Navi like the, a ferry from a legend of zelda. Cause it would just come to your project and add the configuration files in the same way.
Orta: at one point, I spent some time trying to persuade every single tool to use cosmic config. And then I spent some time trying to get cosmic config, to support a single setting where it could be like automatically detect whether somebody has this particular named type of node module. And so if you had a artsy slash cosmic conflict, then every single tool using cosmic conflict would route first through into that, and then come back and start looking in for all these other things.
And I felt that I couldn't persuade them to do it, but I felt that would have been able to allow half like tons of these tools to just not need to have a config in your repo at all. It's still a lot of space and trying to get cosmic conflict because that's what almost every single one of these tools uses to do the work, to accept the work change.
Andrew: Yeah, that's definitely the defacto a solution. Now I use it in countless
Orta: projects.
It's solid. It's really good. They did a great job at it.
Yeah, it'd just be good to get them attacking the centralization problem too.
Uh, yeah. Yeah, I'll do, I'll do, I'll do my own. Shiki two slash which is the code sample generator that I extracted out of the TypeScript website. Again it takes code samples and allows you to use the TypeScript compiler on them to verify that the code samples are correct.
And in the process of doing that, you can use sort of editor level tools like hovers and showing what autocomplete and features like that inside a single code sample. It's like the next generation of what code samples can look like. And it's more or less version one now just wrapping up the final documentation needs.
And so it, it builds on another Microsoft projects, like the person that made Shiki took vs codes, code renderer and then put it on a webpage. So they could put that inside the webpage for vs code. And then I saw that and was like, we should make this a big, proper project. And so Shiki was born and then shiki-two-slash he was born from that And so it's a, it's really cool.
I've been building all these plugins for big static site generators. I'm starting to see the first uptick of people, just using it in their own projects now. So it's really, it, I'm looking forward to seeing to reading other people's code as this because I always want to be able to see what it looks like and to interact with.
It does put my, see what the identifiers mean, especially in projects where syntax, where you try and reduce the amount of syntax possible. Try to keep track of what things are over time is tricky. So Yeah, use shiki-two-slash if you're not.
Andrew: Yeah, Shiki is it is such a cosmic leap in syntax highlighting. If you haven't ever tried to implement something that does syntax highlighting yourself, you might not know like the state of things. And before Shiki, it was like, there were all these different tools that could highlight your code, but none of them would highlight your code like your editor would. And for, from like day one, you're like, Aw, man. Like I just wanted like my pretty syntax theme to be on my web page. And now I can't because of parsing or tokenizing or something, but it's awesome that he was able to take what vs code does. And what I think is actually based on what texts mate did in bring that to
Orta: Yeah. It's funny. I have a friend that the guy that made Jest Christoph Nakazawa. And he started writing these really long form blog posts on how to create Jest from scratch using the Jest dependencies. And it took me about 10 minutes to start to switch his code samples, to use Shiki to slash.
And then he was like, "oh, how do I get all my custom themes?" And then it turned out he'd already built a vs code theme. And so I just copied his vs code theme, jammed it into his website. And then that, that gave his dark mode, his light mode on all of it statically generated to this. No, it runs about your Java script on the user's machine.
It's like super it's really cool tooling, really happy with those let's it's been worth time and effort to make it available for everyone trivially.
Justin: So, cool. Well, thanks again Orta so lovely having you on. It's always great to talk to you. It's been a lot of fun with that. I guess we'll wrap it up for the day.
Orta: always a pleasure. Thanks.
Andrew: That's it for this episode of dev tools, FM, make sure to follow us on YouTube and listen to us wherever you consume your podcasts.
Thanks for listening.