EPISODE 1809

[INTRODUCTION]

[0:00:00] ANNOUNCER: Polypane is a specialized web development browser that simplifies creating and testing modern websites. A key feature is that it provides multiple screen sizes at once, with synchronized scrolling and interactions, so developers can test different layouts and breakpoints simultaneously. Polypane also focuses on accessibility tools, real-time previews, and debugging features. Kilian Valkhof is the Founder of Polypane, which develops the Polypane browser. In this episode, he speaks with Josh Goldberg about his career and the creation of his browser.

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Slint, the tooling that enables ES Slint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on BlueSky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:17] JG: Hello, everyone. With me today is Kilian Valkhof, creator of Polypane, a browser for developers. Kilian, welcome to Software Engineering Daily.

[0:01:25] KV: Hi, everyone. Thanks for having me.

[0:01:26] JG: Yeah, I'm really excited about this. I've been hearing you about Polypane for a while. Before we dive into it, though, I'd like to talk about you a little bit. Kilian, can you tell us who are you?

[0:01:34] KV: Yeah, sure. I'm Kilian. I am in my mid-30s, so for people that do math, which I don't, I'm from the year 1988. I am a developer, a web developer, that just happens to build desktop applications. When I was very, very young, I decided that I wanted to build games, as most of us. I pestered my dad into getting me a Borland C++ environment and then proceeded to understand absolutely nothing about it. At the same time, I discovered Frontpage and discovered that websites do make sense. Now over 20 years later, that's all I do.

[0:02:21] JG: How did you go from discovering a joy of website development to building a browser for people who build websites?

[0:02:28] KV: Well, so when I talk to people about enjoying coding, etc., I'm not one of those people. I've heard developers liken to - they're not specifically clever, which enables them to be a good programmer, or they're not quick thinking, or whatever. They just have a very high threshold for frustration. Because if you're a programmer, all the work you do means that the thing you're working on is broken, or unfinished, or not in the state where you want it to be. That's the frustrating part. Then when the programming is done, it's no longer frustrating anymore, because now you have the thing, but you're also not programming anymore.

I tend to be very annoyed when I'm building stuff, right up until it works. Then I'm happy with the thing I built. But I don't take particular joy out of the art, or the act of programming. But I do really enjoy creating things. The nice thing about websites, and that was right from the start, especially compared to C++, is that you get to experience the results at the speed of a page refresh. That part where I do get my enjoyment from is much more frequent when building web pages. I think that's why I stuck with it.

[0:04:03] JG: Do you remember the first web page that you felt that spark, that happiness from?

[0:04:08] KV: I mean, no. Not really. I started building web pages at age 11. Then I built my web page, my website, as you do. Then the second iteration of that, I had spent months on Flash intro with all the cool stuff, music, sliding doors, sound effects. Getting that done was a lot of fun. Of course, it was Flash. Then the next time I looked at it on a different computer, suddenly, nothing was matched up to the music anymore. It was no longer satisfying. It's all very short-lived, that joy, because there's always something to improve. There's always something where you go like, "Oh, well, maybe I can also do this or this." That's also what keeps me going, I guess, in a way. I'm never satisfied, and that's why I'm a programmer.

[0:05:10] JG: It's almost very pessimistic. At the same time, it's an optimistic viewpoint. There's always something more to do. There's always some more fun to be extracted from the process.

[0:05:19] KV: Yeah. I mean, you can get philosophical about that, because there's this concept of Kaizen, which is continuous improvement, which is something that I know of, but I don't feel particularly strongly aligned with. But I do agree, if you use computers, every day there's going to be something where this can work better, or smoother, or faster. Or if this button was just in this place over here, I wouldn't miss it three times a day and my life would be a tiny bit better. That's just how, or how at least I, as a programmer, and a computer user work.

[0:05:59] JG: At some point, you started taking action on that. How did the Polypane browser project come to be in the first place?

[0:06:05] KV: Yeah. Polypane is actually one in a longer line of apps to scratch my own itch. It started way back building jQuery plugins for things that I wanted. Because jQuery was very friendly. I could start with it relatively straightforward; building things that I needed. I built a tiny helper that overlays a grid on your web page 15 years ago, so I could get everything aligned. Then things for text shadow helpers, etc. Then, at some point, I figured out that you could build desktop applications quite easily, not with all these languages that I didn't know, but with Python, which I knew a little. I spent some time building a bunch of Python applications. Some of them are still easily available, installable in many Linux distributions.

One that I've actually used it today. It's called Trimage. All it is is a tiny GUI, where you can drag your images onto and it will compress them. I built that, because nothing like that existed on Linux, which I use, which I've been using for a very long time. Typing the command line command for that for a folder, or a bunch of files is super annoying and slow, and opening up the folder and then dragging it into the application is really fast. The command is always the same. I built that with Python. It was nice. It was fun. It had a decent layout engine to build the GUI.

Then later on, platforms came out that let you build with web technologies, like Adobe Air, if you remember what that is. Adobe doesn't want you to remember, but it existed. Then from there, other tools like node-webkit. Then, at some point, Atom came along, Atom the code editor, which was built with something that would be called Electron. That was actually where, to me, the promise of using web technologies to build test applications became true for the first time. Because up until then, there was always this huge asterisk where, yes, you could build web technologies, but it used the crappy five-year-old version of a web viewer that came with your operating system, or used some proprietary webkits that was also super out of date.

Electron was like, "Nope, it's just Chromium." You open Chrome, that's Chromium. You open Electron, it's the same thing. Not only did you have immediate feature parity with the web, which most of the other tools didn't have, it was also one of the fastest runtimes for web technology. It was a really good match. I built a bunch of apps in that some, like commercials, some, again, to scratch my own itch. Then Polypane was just one of them where I was like, it's super annoying to resize my browser all the time. Why not just show a bunch of sizes side by side and see how that goes? That's how Polypane was born.

[0:09:29] JG: You bring up the feature set of Polypane, and I'd like to get that in front of folks. For those who haven't played with it before, what are some of the, or at least what's the same draw of Polypane, the browser?

[0:09:39] KV: Yeah. There's really two areas where Polypane gets used. The core idea is use a web developer, need to do a lot of stuff to build a quality website. A lot of things that are quality are very hard to do in a regular browser. Because a browser is actually working against you a little. For example, if you write really shitty HTML, garbage HTML, or all uppercase, you don't close any of the tags, then your browser is going to go, "Well, it's fine. It's fine. We'll just try." It'll start fixing all these things for you to make sure that the promise of the web interoperability is preserved and the end user still gets to see something. Then at the same time, it's like you lying to yourself. I build something and it works in the browser, but it works despite what I did and not because of what I did.

Polypane flips that around and it tries to make everything you do really easy to see. It started with responsive design, where if you build a website, usually what people did was they did the desktop site completely and then they resized it to small and then they started fixing and then maybe they would go back to desktop and see what they inadvertently broke while fixing the mobile version. Usually, if you do that, it's going to take a couple of times to go back and forth, back and forth, back and forth per page to make sure that you didn't miss everything. What if you just had those two views side by side and then also another view in the middle, or maybe you had five different views, because these are all the functions you care about. That's something Polypane does.

You can see your web page at all these different sizes, and then also, all these different emulation modes, so you can have one viewport pretending to be an iPhone, one pretending to be a Galaxy tablet, one pretending to be a Windows device. You can see how your web page responds in all these different situations. Then, in addition to that, also with light and dark mode, rather than flipping your entire operating system from light to dark mode, or to force color mode, or increase contrast, or reduce motion, or all these things that you can develop for, in Polypane, you can do the same thing, but it only affects that single viewport. You still get your code editor looking normal and you still get your animations in all the other places that you do want them, but you get to test your website in all these different variations that it comes in. That's the one part.

The other part is accessibility. Doing accessibility well is really hard, again, because the browser hides a lot of stuff for you. If you have a diff with an on-click handler, then your browser is just going to go, "I know what clicking is, there's an on-click handler on this thing. If you click it, then I'm just going to do the thing, because that's clearly what you intended and we're just going to roll with it." If I'm a keyboard user, I can't go to that diff. I can't click that diff. I can tap to it. If you are a sighted user, if you are a mouse user, then knowing that that's wrong is really difficult, because there is nothing wrong for you. It works the way you built it and it works the way you test it. Polypane gives you all these tools and warnings and suggestions on how to improve those things in essentially, all areas of accessibility.

[0:13:24] JG: That's really lovely. Every team I've been on has a few people who are excited about accessibility, a few people who are maybe not excited, but certainly happy about it. Then the rest of the people who have those energies in other, perhaps, also, important areas. It's nice to have a tool that will apply that same line of thinking for us. They use a button and not a diff before clickable elements automatically.

[0:13:46] KV: Yeah. What I think is important, I think at some level, everyone cares about accessibility, because accessibility isn't just, I can't see the web page because I'm blind, or I can't cross the street because I'm in a wheelchair. There's also accessibility in the sense that maybe I have carpal tunnel and now I can't use my mouse very well. I'm going to have to adapt. What I really try to do in Polypane is to make sure that it doesn't just tell you what you're doing wrong, because there's tons of tools that you can use that will tell you all the ways you are building websites wrong and you can run them and you get a list of a dozen things and you're like, "Yeah, my project manager doesn't care about any of these, so whatever."

What I try to do in Polypane is I'm going to tell you what's wrong, but then I'm also going to hand you the solution, or the fix. That's even if you had the good intention, like this is an issue that I didn't know was an issue and I'm going to fix it and you're going to go to your search engine and you're going to find five different ways to solve this issue and you're going to have to choose which one is the one that's right, or I'm just going to move this ticket to done, because again, my project manager isn't going to judge me for it.

If Polypane goes, instead of this, why not this, you can just copy and paste it, then you're going to copy and paste it and again, drag the ticket to done and move on with your life. In the meantime, you've improved the accessibility of your website. Really try to help people in the sense that you don't have to be an accessibility expert. You don't have to wake up every morning screaming, "Accessibility," to make your website a little bit better every day.

[0:15:41] JG: I'm looking at the Polypane.app website. A couple of things jump out. One, really good-looking website. Nicely done.

[0:15:46] KV: Thank you. Yeah.

[0:15:47] JG: It's also very accessible. I'm tabbing through. But if you look at the home page, right, bright and center is this lovely screenshot of Polypane. You can see that as you're describing, the screenshot shows there are three different browsers, iPhone 11, iPhone 14, then a light mode of another one. Then on the side, you've also got some other information that's not normally there in other browser dev tools. You've got this info with meta and site info that's saying the doc type, the viewport, whether it's mobile friendly, and so on. You're also adding a lot of metadata to what developers see, right?

[0:16:20] KV: Yeah. A regular browser shows you your webpage, but your webpage contains way more information. Primarily, all the stuff you put in your head. I'm sure every developer listening to this podcast has at some point, had to fix a title, or a description, or an OG image in production, because they missed it, because it's very difficult to figure out that the description is still placeholder of text. In Polypane, there's all these different lenses to look at your website, and one of them is what's the meta information? Because that meta information gets used when you share it on X, or when it pops up in a search engine, or when it gets syndicated with your JSON LD data, or when there is a security issue, people will see if you have a security.txt file in the well-known folder with contact details and is that still up to date? Does it exist even?

All these things that surround the visual design, I think also are important. They're, again, also marks of quality. It tries to make all of that easily accessible and easily inspectable. Those are hopefully, also, easily improvable.

[0:17:43] JG: I'd like to dive in at some point to how you did all these things, these meta-analyses, and you mentioned using Electron. Are there any features we should surface before we go deeper?

[0:17:53] KV: Not for this. Usually, when I give a demo, I can give a demo of an hour of just me talking about all the features and then at the end of the hour, I go, "Oh, by the way, we also have -" Then of course, that's always the killer feature for the people I'm giving the demo to. That's how it goes. Yeah, we could deep dive into any aspect of Polypane and there's going to be additional features.

[0:18:20] JG: Great. Let's deep dive now. The first, the banner feature is that you, I think you show multiple browser viewports of the same page at the same time. How does that work?

[0:18:31] KV: In Electron, there's this concept of a WebView, which is essentially an iframe with extra permissions. On the web, iframes are very limited. You can't just randomly iframe apple.com into your website, because that would be bad. If you are a desktop application, then showing web pages is one of the things that does make sense. Desktop applications are trusted. You give them access to your file system, to your system information. They are privileged in that way. Then to make sure that there's a proper separation from the privilege part of your app and the web page that you're showing, you can use WebViews to split that up. Then what Polypane does is it actually communicates a lot into these WebViews. They call it the main world, which is where your JavaScript runs. Then there's an isolated world where my JavaScript runs. They're completely separate. You can never get to Polypane's JavaScript and vice versa.

I use that isolated world to make sure that I can sync all the actions that you do. Because just showing multiple sizes is neat. If I type in one of the viewports, I want it to open everywhere. If I click submit somewhere, I want that to happen everywhere. If I scroll, if I hover something, I want to make sure that the hover style is correct everywhere. Polypane syncs all the interaction events across all the panes, so that you're really interacting with one page. You just happen to be seeing it at a bunch of different sizes.

[0:20:13] JG: Hang on a second. Syncing events across pages. There's a difference between a naturally created keyboard, or mouse, let's say, event, versus a synthetically created one by JavaScript. How do you make sure that the pages all experience the events in the same way?

[0:20:29] KV: This is where it gets really technical. The difference between a regular event and a synthetic event is something that you as a programmer don't have to care about, but some frameworks do. For example, React and Vue, they have different code for handling synthetic events compared to real events. I try not to get too clever with things, so I am sending synthetic events in all the other places. Then I'm tricking React and Vue into still accepting it, even if it's synthetic. Then that synthetic events really only matter for things like clicks, clicks and form submissions and things like that. Whereas, scrolling, hovering, focus, these are more easily replicated across viewports.

[0:21:23] JG: It's interesting though, when you think about it, it really is just with quotes around it, a WebView, which is a glorified iframe. Anything that happens, one WebView can be copied to others. Let's say I'm a developer and I'm, of course, tinkering around in DevTools, is there a way for me to say, apply my tinkering to one WebView and have it be copied to all the other WebViews at the same time?

[0:21:46] KV: Yeah. I actually built my own elements inspector and my own console. Because Electron is built on Chromium, so you get the Chrome DevTools for free. But the Chrome DevTools are built in a very particular way, namely, one website or web page gets one DevTools. That's never going to be different in Chrome. That's just the way it works. Yeah, like you said in Polypane, if I'm going to increase the font size of my heading, I want that to happen everywhere. I built my own elements inspector that it takes all the styles, it parses them, it lists them in order of specificity. You can live edit them, there's a little color picker, you can disable them and enable them, anything that you want from an element inspector, except that it applies your changes to all the viewports that you're looking at right now.

That was a massive amount of work, and I had to rewrite it a bunch of times to improve the way it worked. I'm now at a point where the stuff I build is now getting copied into Chromium and Firefox, etc.

[0:23:01] JG: That's a big, how do they say, feather in your cap. What are some features that are being copied over?

[0:23:07] KV: Recently, two years ago, we got CSS nesting. Initially, DevTools in Chrome just didn't display that, because they didn't have code for that. Polypane was actually together with Safari, the first to show nested selectors in the element inspector. Then Chromium got them and then they iterated and they iterated and they iterated and then they ended with the design I launched with.

[0:23:37] JG: How does that feel?

[0:23:38] KV: I mean, that makes me feel like I was right, which is always a great feeling. Also, there's two parts to it. Of course, I don't want them to copy me, but I'm building a browser, so I am also copying them in a way. I want everyone to use Polypane, so all the features that are cool in Polypane, if they end up in other browsers, that's also annoying. Also, yeah, I came up with a design that worked so well, that one of the largest companies in the world is now doing the same thing, and that feels really good. That also means that I'm striving to continue doing that.

[0:24:17] JG: Let's talk about that last bit, striving to continue innovation. You are but one person. There are quite a few people working on each of Firefox, Chrome, Safari. How do you keep up with all the latest and greatest, given that the web platform is continuing and continuously evolving?

[0:24:33] KV: Yeah. I am a single person team. That's true. What you need to understand, or what you do understand, but I don't implement web features myself. I get Chromium for free. If Chromium implements CSS nesting, I just have to make sure that I can display that correctly. That's if, for example, I inspect a specific nesting and it crashes in a specific beta version of Chrome that I happen to be boiling that on, that I communicate that to the developers so that they can fix it before the proper race. All the features that are showing web pages are built for me in a way, and I just have to make sure that the inspectable parts, the DevTools part is also up to par.

[0:25:27] JG: What did you build the DevTools part in?

[0:25:30] KV: The entire UI is built in React. I started PolyPane as a site project back in 2015. It's coming up to a decade, which is insane. That also means that I started with React 0.13 and I've just slowly layered up. It's running React 19 now. I try to keep up with all the latest releases, as soon as they come out. Because there's a lot of benefits there. Usually, it's not a lot of work. Yeah, so that's all the visual stuff is React, React components. I still use a whole lot of class-based components. One, because they are already built and I'm not going to rebuild them just for the sake of rebuilding. Also, I prefer class-based in many situations, because I really like life cycles and they make a lot of sense to me. They are very clear in class-based components, and you can do stuff to the life cycle that's much easier to grasp than functional components.

It's a bit of a mix, where larger components that do need more life cycle management, which you do if you're managing the entire CSS of five different viewports at once and you're trying to combine that cleverly, there are going to be a lot of places where, "React, not right now. Wait a bit." Stuff like that. Yeah, it's all React.

[0:27:07] JG: Your performance characteristics one has to imagine are quite different from the typical web page. Those web pages are fairly static, even if they have interactive bits. Yours is extremely intensive.

[0:27:16] KV: Yeah. That's very different from the usual, like what people care about in performance, because if you look at resources for performance for React, it's all about smaller bundles, which makes sense if you're loading a web page from the network and download time is directly affects the speed with which your web page is visible and interactive. I'm a desktop app, so my bundle size is over 10 megabytes. That doesn't matter, because I'm also shipping chromium. The 10 megabytes isn't going to be the bottleneck there. The startup time of a desktop app can be different to the startup time of an app. Yeah, I think I said that right. Website versus app, app can be slower to start up.

Then, what does become important in Polypane is that it might be running for a day. If there's a memory leak somewhere, where there's one event listener that I'm not unregistering, then that might end up being 2,000 event listeners by the end of the day. That becomes an issue. There's a lot of very different types of things that I have to care about, where on the web you're like, we'll just add an HTTP refresh for every five minutes and it'll be fine for the next couple of months, until we do a root goals analysis, etc. I can't go around refreshing the app.

[0:28:53] JG: That would be quite frustrating. How do you test, or how do you validate over time that your performance characteristics for people running a browser aren't broken?

[0:29:02] KV: A lot of it does come down to feel. I use my browser all the time on, like I have a Linux device in front of me right now. I have a Mac device to my left and I have a Windows device to my right, and they're all running Polypane right now. It's a lot of manual testing. Then the Chromium DevTools performance tab is really, really useful. It allows me to very specifically check for specific interactions in the app, because I can start a performance trace, do a specific action and see its outcome, and then very quickly iterate on that.

[0:29:44] JG: That's a nifty. You've got the holy trifecta of operating systems in front of you. It's a nifty for what you got.

[0:29:49] KV: Yeah. I've been using Linux as my main operating system for the past decade. I vastly prefer it to the other two. If you build a product for developers, you need to be on all the operating systems. Then also, it needs to feel right on all the operating systems. The app is slightly different on all three operating systems to make sure that I do somewhat stick to the, like how do you operating system handles closing and opening, or where the close buttons are, or how the menu is presented, to make sure that it does feel cohesive with the rest of your device.

[0:30:30] JG: That's a good segue. I'd like to move into some of the final stages of the interview, talking about what's coming next. Speaking of working across devices, could you tell us what is Polypane Portal?

[0:30:41] KV: Yeah, so Polypane is a web browser. It lets you build websites and test that, yada, yada, yada, but it only runs Chromium. You can have a viewport in Polypane that pretends to be like an Android phone, or pretends to be an iPhone, or pretends to be Firefox. That's very useful, because then you can test if your code responds well to running in that environment. Say, you have a polyfill that you only apply to Safari, you can test that in Polypane, because your code will decide that, okay, these are the characteristics of an iPhone, so I'm going to load my polyfill now. Then you can test your polyfill without you needing to trot out an actual iPhone.

However, if the issue is on the other side, if there is a bug in Safari, or if there's a rendering issue in Firefox, then Polypane isn't going to help you. That was very frustrating to me, because that means that you do have to then go and open Firefox and then manually do all the same things you were already doing in Polypane, but in Firefox, or even worse, on your phone you have to bring up your IP address for your local host and then type in your IP address and then you miss a dot and you have to type it again and it's just annoying.

Portal is if you're running a local server and you have that open in Polypane, you can open a portal and that will proxy your local server, either to your network or through a public URL to the entire world. Then you can open that either by sending that link, or you can show a QR code in Polypane and you can open that on all your devices and you can have them laid out on the table and then it's the same thing. Anything you do in Polypane, whether that's scrolling, or editing styles, or clicking or typing, it happens on all of the devices around you. That solves the issue of you want to use Polypane, you still need to test all these other browsers, all these other devices. You don't want to do that one by one, because that's slow and boring. Now you can do all of that in one go as well and you can still interact with all of them through Polypane. That's what Portal does.

[0:33:10] JG: I could see a future in which Portal is pulled into as even part of the default experience. Why stick with Chromium if you can just use the user's native browsers?

[0:33:20] KV: There is no you can use the native browsers on desktop. If you are on Linux, or if you are on Windows, there is a WebKit. Yes. You can compile it and you can run it. But if you take that WebKit and you hold it next to an iPhone, it's not the same thing. It's very different. You want to be testing the iPhone, not the WebKit on your device. There is no way to do proper cross-platform, cross-device testing without real devices, as much as I would want to embed Gecko and embed WebKit in that manner.

[0:34:02] JG: What are the other upcoming features you're excited about with Polypane?

[0:34:06] KV: I actually just released a version today. I released a version roughly every month. Today's update was a little bit minimal, because I also took a Christmas break. But it's running on the latest Chromium again. I keep that up to date with Chromium as quickly as possible. Chromium 132 came out on the 8th of January. It had a rolling release in the past week. Then yesterday, Electron updated to using that version of Chromium. Then today, it's running in Polypane and you get parity with what your actual users use. That's very important to me. That does mean that it's very light on other features.

One neat thing that I built is that if you use Portal, it now announces itself through something called MDNS, which if you're on Mac, you might have heard as Bonjour, the Bonjour surface. Essentially, what that does is it solves the issue of there is a thing in your network that can do a thing, or a device in your network that can do a thing, but you don't know where it is. You don't know its IP address. MDNS is a way for all of the devices that you have to broadcast, "These are the things I have available." If you have a Chromecast, for example, that connects to your apps on your phone, or your Google docs, or whatever through MDNS. If you have Netflix open and it detects your Chromecast, that's because your Chromecast is sending an MDNS message saying like, "Hey, I'm a casting device. Here's my details."

Polypane now also does that for Portal, which means that if you have an app that sports MDNS with HTTP, that will show up. Then you no longer even have to copy that link, or scan the QR code. You can just push the big button that says 'Polypane Portal', and it will open that URL for you, which is very cool because I am working on an iPad app for Polypane that also uses MDNS to detect portals. That way, everything just gets even faster. You can start a Portal in Polypane, open up your iPad app, push the big portal button and you're up and running on your iPad, in mobile Safari as well.

[0:36:40] JG: That's got to be really convenient for people who are not used to scrolling through DNS, or local networks to set up browsers.

[0:36:48] KV: Yeah. Apparently, it's a very clunky protocol, but there's a couple of NPM packages and React Native packages that make it super easy. You start listening and within a couple of milliseconds, you have a list of all the devices on your network, which can be confronting, because you're like, "Why is my Mac sending out all these services? What's this weird IoT device doing?" That might be fun to do as well. Then you just have that list and it's a list that says, these IPs have these services on these ports, and then it's up to you to figure out which ones are interesting.

[0:37:31] JG: I want to surface a couple of other things, since you bring up that you have new releases, there's a blog that has articles for each of them. First of two, you mentioned by name people who contribute, or give ideas. That's a really nice thing you do.  That's lovely. I can tell a lot of developer, or developer-oriented projects do that. It's like from the auto-generate to GitHub class, but it's obvious in the changelog that you've hands done that. You manually shouted people out.

[0:37:54] KV: Yeah, I started doing that. I always did it, but I did it in private. It was like, "Hey, the thing you requested now exists. Hooray." Then at some point, I was like, why not just also tell the world that people came up with good ideas and also, publicly thank people, because it's a nice thing to do. It makes me feel nice. It makes them feel nice. It might help other people realize that they can also give suggestions, and there's a high chance of that being implemented. Because I think a lot of developers, their experience with using tools is like, there's this tool. I might not like certain things about it, but it's never going to change because they won't listen to me. Well, I'm just Kilian. I'm a single guy. I'm one guy. You can email me. You can DM me. You can go to the Slack channel. If you have a good idea, then I can implement it. I want to implement it.

I think, yeah, I think it does make it much nicer. It also makes it much nicer for me, because if I'm implementing stuff and I'm implementing it for specific people, then I know I'm making them happy, and that makes me happy.

[0:39:08] JG: You seem happy. This is an audio-only podcast, but there's a sparkle in your eyes. It's very nice to see. The other of two, two of two is, that's a great segue, that there are a lot of people who don't realize, I think, what Polypane, is or what's available to it. You have a blog post from November, 2024, where someone who's quite well-known, Adam Argyle on the Chrome DevRel team, asked on formerly Twitter, what is missing from the Chrome DevTools? You, in this blog post, break down all these different, very common requests and explain exactly how they map to built-in features into Polypane. Your thing is almost seemingly quite literally the most requested features from DevTools, just in a box.

[0:39:49] KV: Yeah, yeah. There's a reason those things are the most requested features. That's also why I tend to have them implemented. As I said, I use Polypane myself all day. Anything where I'm like, "Wouldn't it be great if it could also do have a JSON viewer?" Sure. Now Polypayne has a JSON viewer. That's built-in.

[0:40:11] JG: That is nice.

[0:40:13] KV: Yeah. I mean, that is nice. It took me a week to build a JSON viewer, figuring out what are the things I want in a JSON viewer. I think I do some neat things that I haven't seen in other JSON viewers, where it's very easy to collapse multiple sections. It gives it, again, it parses through your JSON file. Then if there are repeating structures, then maybe if it's a GitHub repository, there's all the releases and then all the releases have assets and then all the assets have download links. If those are all opens, then it's just endless scrolling to go to a specific release. Then if there's a big button like, collapse everything, then you're like, okay, but now I have to first press the collapse everything and then go back to releases to un-collapse that, and then that's two steps.

In Polypayne, I can just list all the things that have subsections, and you can go collapse everything that's called assets. Now, you have a neat little list of releases that you can quickly scroll through and get the stuff you need, rather than doing excessive - I really hate doing management stuff in my apps. If I need to do something and then undo it to do the thing I actually wanted to do, like that's one step too many, and that's annoying, and we need to fix that. That just permeates throughout Polypayne, beginning with, I don't want to resize my browser. I don't know what I'm doing. Just gave me the sizes. I know what the sizes are. Just give them to me.

[0:41:57] JG: Well, that's a beautiful full-solved problem moment that we can close out the discussion on Polypane on. Kilian, I have one last question to ask of you in our final two to three minutes together. What is it with you and apple cider? Could you tell us about that?

[0:42:10] KV: I mean, yeah. Sure. I really enjoy apple cider, which, to be specific, I'm talking about European apple cider, which is hard cider in the US, and I've made my own cider in the past to varying degrees of success, because it's very difficult to get it, like the taste of UK cider, or a French cider. Right now, I'm making an ice cider liqueur. Ice cider is made from apples that have been frozen. If you freeze apples, then a lot of the apple breaks down, and they become much sweeter. An ice cider is almost a dessert wine, and it's very tasty. I recently had one after having had it in my cupboard for three years, and then finally, going like, "Maybe we should taste this." It's a nice bottle, and we've been saving it up for, we don't know for what. Let's just open it now, and it was extremely tasty.

Then last Christmas, we were together with my extended family, or with my family, and both my parents and my brother came up with the same idea, which was, let's all make a liqueur, and then have a tasting together. Everyone comes up with their own liqueur, and when they're all done, we'll go and taste them together, which was hilarious because my parents, they came out with bags with a bottle of vodka, and then stuff to build the liqueur in, and they handed it out to everyone. Then my brother was like, "Well?" Then he came out with the same bottle of vodka to give to everyone.

For the past week, I bought local apples, and I cut them up, and I froze them for a couple of days, and then I unfroze them, and I chop them up some more. Now they're sitting in vodka, and they'll have to stay there for at least two weeks. Then I can filter it and bottle it. Then I'm going to add some apple molasses, which is apple syrup, but very dense, very thick, to back sweeten it, or to sweeten it. Then, at the end, I should have an extremely tasty liqueur, and I look forward to that succeeding. I hope it succeeds, because it is an experiment.

[0:44:47] JG: That sounds fantastic, though. I mean, I've never heard of this iced apple wine before, and it sounds lovely.

[0:44:53] KV: Apparently, it's a thing from Canada, which makes sense. They have apples, they have ice, so.

[0:45:00] JG: Those two things are very in abundant qualities, and quantities, and come back.

[0:45:05] KV: Those together, if you make cider out of those, then apparently, it becomes much sweeter, syrupy.

[0:45:12] JG: They have that in Canada, too.

[0:45:13] KV: Yeah. One of the options was sweetening with maple syrup, but I am going to sweeten with apple just to get even more apple-y.

[0:45:24] JG: Excellent. Kilian, I'm going to be rude and insist that the next time I visit Amsterdam, we will connect, and I will try your spirits. I look forward to this.

[0:45:33] KV: Yeah. Happy to host you.

[0:45:35] JG: Great. Well, all that being said, I had a great time this episode. Happy 2025, everyone. We covered Polypane, how it came to be, a lot of the features we dove into, how it's created, how it's constructed on top of Chromium and Electron, and we talked about some of the newer stuff. Kilian, is there anything else you want to leave us with before we head out?

[0:45:54] KV: Yeah. Anyone listening, please try out Polypane. There's no strings attached. You can just download it and try it. I'm not asking for your credit card. If you do try it, let me know how it goes. If you have clever ideas, good suggestions, I'm all yours.

[0:46:12] JG: Excellent. Well, this has been a fun interview. Thanks, everyone, for listening. I'm Josh Goldberg with Kilian Valkhof for Software Engineering Daily. Cheers, everyone. Bye.

[0:46:21] KV: Cheers. Bye-bye.

[END]