Kilian Valkhof: I describe Polypane as a browser but for building websites and contrasting that to other browsers, which are really good at browsing, watching cat videos on Facebook, et cetera. Paul Mikulskis: Hi there and welcome to PodRocket, a podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free today at logrocket.com. I'm your host, Paul Mikulskis, and we have a fantastic guest joining us today, Kilian Valkhof. Kilian is a front-end developer, user experience designer, and self-proclaimed strange generalist, amazing term, who is passionate about creating tools and helping developers, designers, and others. Welcome to the podcast, Kilian. Kilian Valkhof: Thanks for having me. Paul Mikulskis: So today we're going to get into Polypane. I'm going to give a really quick intro to what Polypane is, but I'd love to hear your rendition of it. But really quick, Polypane is a cross-platform browser built specifically for web developers and designers to streamline and optimize their workflows, and focus on streamlining and optimizing process and workflows and your speed of development. With its innovative tools and features, Polypane can simplify your process of creating, testing, and debugging responsive websites and the landscape for the modern web. And it's a complicated landscape, so there's a lot of things you need to take into consideration and Polypane is here to kind of help you out on that. So Kilian, when did you embark on the journey of making Polypane? And I'd love to hear your version of the value of Polypane, what it is. Kilian Valkhof: Yeah, sure. So if we start with that last bit, because when I started out with that journey, I definitely didn't know what the value would be or is now. So usually I describe Polypane as a browser, but for building websites and contrasting that to other browsers which are really good at browsing, watching cat videos on Facebook, et cetera. They're very heavily optimized for that. Of course, they have dev tools and really good those dev tools, but they're also kind of hidden away, stuffed in a little box, and they're not allowed to touch the rest of the browser because that would scare everyone that uses the browser to cat videos on Facebook. Polypane kind of flips that around. The idea is what if the entire browser is the dev tool and what if that dev tool does more than just telling you that you did something wrong or that something is slow or that things don't work, but also tries to go the extra step and point out, this is something that's wrong, but here's how you fix it or here's something you can use that does work. So really focusing in on what are the thousands of paper cuts that you experience every day when building websites that are annoying, that take you out of your flow, that force you to go to MDN, Stack Overflow, just Google searching, and what if we can prevent you from leaving the thing you're working on and instead having you stay with what you're working on and giving the solutions and the fixes while you're working on your project. Paul Mikulskis: And that sounds like a lot of extra visual feedback I'm going to get if I use this tool. So it's going to point out this is not right or your contrast is not being considered here or you need an OG image, this is the type of things I'm thinking. Or if you go to the website, the paramount view that's displayed as, oh this screen and that screen all at once. Kilian Valkhof: Very visual. There's a ton of tooling in there. I don't think anyone uses all of it. I don't use all of it. I do think everyone uses their own 20% of the tooling and then combines, everyone uses everything. And then all the stuff that's there that you don't need, the moment you do need it, it's there. For example, I have a debug tool that helps you test whether or not your web components are properly isolated from the rest of the CSS styling. If you don't use web components, you're never going to use that tool, but then the moment you do, when you do need to check that, it's there. It's a single click and you can improve your website. Someone when I described this 20% thing saids, "Oh, so it's like Photoshop for developers." I really like that because one, it's very good for my ego to be compared to something like Photoshop. But it's true, if you use Photoshop, there's hundreds and hundreds of tools in there and no one knows all of them. And everyone has their own little workflow in Photoshop that works for them using 20% of the tools, and that's fine, that's how it works. So that's what I'm trying to do with Polypane as well. Paul Mikulskis: One thing that caught my attention as a developer from the developer perspective is that it's not just a set of tools, but it will give me more errors in a place I might not see an error, or it might have some behaviors that the browser maybe is not spec-compliant fully. I am not an expert on spec, I don't read specs, but I know there are magical things the browser does to make a better user experience for me. That maybe Polypane doesn't hide or abstract, that as an engineer it pushes me towards being a better engineer. And to me, that's neat because it's not just like here's a tool, it's like, here's something you got to do more like an IDE. It's stepping to the IDE realm almost a little bit because it's helping me develop in an environment. Could you talk to some of these guardrail features? Kilian Valkhof: So the thing you need to realize with browsers is that browsers aren't built for you, the creator of the website, browsers are built for people viewing your website. So what browsers are really good at, what browsers are built for is taking whatever garbage they receive and making something of it, making sure that the user sees at least something. That's where HTML and CSS, that's their whole thing. You can send broken HTML and broken CSS and the browser will still make sure the content is accessible through clever parsing tricks. Another very clear place where the browser does that is with URL handling. A lot of browsers do really clever stuff with the URL you type into the address bar to make sure you actually go to where you think you're going, regardless of what the server does with that specific address. Like a very clear one is the www subdomain is actually just a different place than the domain itself, and if you don't properly forward from one to the other, then that is an issue. But browsers all of them make it very hard for you to figure that out because if a browser goes to www.example.com and that doesn't exist, it returns a 404. It just very quickly tries example.com without the www and then gives you that because that's obviously what you as a user wants it. That's a great user feature, but if it's your own site you probably want to know that's happening. So in Polypane, I don't actually do anything all too clever with the URL, and sometimes that confuses people because it works in Firefox. But yeah, it does mean that it sort of exposes the way your server actually handles these requests. And then browsers do a ton of other fun stuff with adding and removing slashes at the end. Firefox for example, if you type .CMO and then press enter quickly enough, Firefox will decide that's a typo you made and rewrite the URL to say .COM for .com. You can try that out now if you're listening to the podcast, Firefox will just pretend that you wrote .com. Paul Mikulskis: Learn something new every day. I had no idea. Kilian Valkhof: Yeah, that's an awesome feature and it's also not something you want to happen to the URLs you are developing at this moment. Paul Mikulskis: So we got some guardrail features and I feel like you have to make this decision about is this something that's going to annoy people too much. Is it going to help them? For example, I listened to this one podcast Kilian with you on and you were giving an example of auto-save and you were like, "Okay, I made this thing that when I auto-save it, a message pops up and it's like, your work is already saved. And that's fine and dandy, but if you had a message for 10 different things and they're popping up all the time, you would drive users crazy." So I'm curious as to what are one or two features or guardrails that we were just talking about that you felt like you were walking the line on that you threw in or you didn't throw in. Kilian Valkhof: So one of the things Polypane does is it warns you when you have too much CSS. Paul Mikulskis: Too much CSS? Kilian Valkhof: Yeah. So if you have 10,000 CSS selectors, then Polypane throws up a little warning. It says, you have way too much CSS for a single page, there's an issue there. And the reason I'm showing this warning is twofold. One, it is a quality issue I think. If you're shipping that much CSS for a single page, then you're doing something wrong, or more generously you can improve that. It's also a size issue, you have to download all of that. But also Polypane parses all your CSS to do all sorts of clever stuff, and parsing 10K selectors just takes longer than parsing 5K selectors, so it's something you're going to notice at some scale, which is why I show the warning so that people know what's going on. In the upcoming release, I actually changed that from showing the warning every time you loaded a page with too much CSS to just showing that warning once because not everyone has full control over that and they still need to get work done. In the next release, I'll show the warning once so people know that there's an issue, and then they can just get on with their work. And that's the result of user feedback where a bunch of people said, "I know I have too much CSS, this is an issue. I don't mind the pop-up telling me that it is an issue. But I know, please let me get on with my work." And that's fair enough. It's also a matter of four guardrails that I don't myself experience. I really depends on user feedback on where to put them and how much leeway should there be. When it comes to notifications, that's the trickiest. The rest is easy because if I give suggestions for your heading structure like your H1, H2, H3, et cetera, that's in a panel and you open that specifically to get feedback. That heading structure, there's not like a pop-up in your face, so you have much more leeway there and it's much easier to show warnings, et cetera. It's only with time-sensitive stuff or notifications, you have to be a little more careful. Paul Mikulskis: Now you mentioned a notification, like you said, "Oh, the application will give you notification." I assume it's like some card that pops up or breadcrumb, but that begs me to start to think about what does it feel like to use Polypane and who should be using it. Is it just for independent developers, for teams? Like you mentioned right now with the CSS problem, like, not everybody could have control, and that suggests there's a team using it, you have setups and cross-repo, cross-team. So you engineered this out of your own need, you were like, okay, I want to make myself faster here and here. So it feels like a personal dev tool, but you're raising it up into this bigger responsibility now where it could really accelerate a team. So who do you see using Polypane now and making the most use out of it? Kilian Valkhof: Yeah. So it very much started as a tool that I myself needed when I was a lead front-end developer at an agency. So I was doing developments, but I was also doing QA, I was also reviewing designs, and I just noticed every time I had to resize the browser, felt dumb. And one of my personal pet peeves is if I need to repeat myself or do the same action every time, that starts to feel very annoying, so I want to automate that or get rid of that, which is also why I built that auto-saving Notepad. Because I noticed myself pressing command S all the time, I was like, "This is dumb, I just want it to save always. Why do I need to manually tell it to save always?" So I built something that just always saves. And I had that tool which helped me do my work, review different sizes and different screen sizes, and aspects, et cetera. And then I started sharing it with other people and then all the other people were developers as well, so there were tons of really cool feature requests. "This is cool, but I really want to screenshot this so I can send it to the customer or to the designer because this gives a really good overview," so implemented that, et cetera. And then if you look at the people using Polypane nowadays, it's really anyone that has influence over the end result of a website or a web app. Like very concretely, it's a front-end developer while building the websites, it's QA while testing the websites, it's design roles who also have to do QA or verify that designs are implemented, it's project managers that want to get an update of the status of the project and then they can do the screenshots and send it to the customer and have a fancy reporting. It's pretty broad. And then it also doesn't really matter what team you're in, just like it doesn't really matter which browser you use if you're working on a project. Polypane doesn't really benefit teams as much as individuals within those teams. Paul Mikulskis: Okay, I really like that. It doesn't benefit teams as it does individuals within those teams because I would assume there's such a rich set of features and stuff, you really need to know what you're looking for. You can really get niche with your use case of it and you can really extract value. As like you said, a project manager, that's something I wouldn't initially think off the bat, but you can get a lot of in-depth information for your specific use case if you know what to look for in the tool because it can surface unique insights. Kilian Valkhof: Yeah, exactly. Paul Mikulskis: And as for bug tracking and issue finding and things like that, when you have all the different viewports in Polypane, do you think that is the number one biggest help and accelerator when you're developing a responsive design and you're solving bugs? Kilian Valkhof: So one of the things that's actually a little hard to realize unless you're using Polypane is that on the web we can design and build desktop first and you can design and build mobile first. But what's really happening most of the time is that you're working on a page and say you're doing mobile first, you do the mobile, you do the tablet, you do the laptop, you do the whatever, 4K desktop. And then you move on to another page and you start with mobile again, but then maybe you're adding stuff that affects the rest of the screen sizes on that other page or you get some feedback or there's a redesign or some updates. And if you do mobile first or if you do desktop first, what you need to do is go back to one and start with mobile again and then tablets, laptop, desktop. So you're making that same loop over and over again and always starting back at mobile. Whereas if you have all those screen sizes in one overview, you don't really have to choose for one because any change you make, you can already without any additional cost to you in terms of time and efforts, see the result of that change across all different sizes. So it really speeds up that process of to say poetically like sculpting a website. If you have your website, the design might be fully done, but you start with the header because that's complex and then you do the header on mobile, tablets, et cetera, and then that's done and you move on to the next section on that page. If you only see mobile, then you only have the context of that header with the context of that next section. Whereas in Polypane, you have all the variations of that header for all the different sizes already visible while you add to that page, so there's a lot less going back and forth. It saves so much time and that's really hard to realize without actually trying, but it does make a lot of difference. Paul Mikulskis: And I'd also just like to point out that there's very fair arguments that there are other tools out there that might offer, oh, you can do a side-by-side view of things, but the value add, at least I would feel as a developer here is having these personal helpers, Kilian because they come from your own areas of need and frustration. When you combine those with the multiple viewports, that's where you can really accelerate your insights about what's going on. And I'll take this one moment to just add-in. If you want to take your bug-solving and finding issues even faster to the next level, I'll remind our listeners that the podcast is brought to you by LogRocket and LogRocket also offers session replay, issue tracking, product analytics, and it can help you quickly surface and solve impactful issues affecting your user experience. Try LogRocket today and squash and find your bugs faster, improve user conversion and adoption. Kilian, turning back to Polypane and bug squashing and issue finding, what is one feature that you came out in the suite that you didn't initially plan for that a user came to you with and they were like, hey, I keep having this issue, it'd be really great if you could add this in and you're like, okay, yeah, let's do it? Kilian Valkhof: Mm-hmm. I can give two examples. So two days ago a user asked me, "I have this browser extension that when I select text it tells me how many characters are in that selection." And that's useful because you want your paragraph lengths to be roughly 60 characters long because there's different fonts, you don't really know if 500 pixels width is 60 characters. It's like a really quick select text, right-click, get the number of characters. So they asked that, I thought it was a cool idea and then 10 minutes later I sent them a screenshot with the feature. Paul Mikulskis: 10 minutes later. Kilian Valkhof: Yeah, I timed it, it was 10 minutes. I did spend longer on it afterwards because I had characters and I was like, "I also want words and then maybe also I want a separate counter for emoji," so I built all of that. And then another user that I showed it to ask me, "Okay, cool, but what about Chinese and Japanese?" And I know nothing about Chinese and Japanese. I found like a word counter on npm that supposedly supports Chinese, Japanese, and Korean. The acronym for that is CJK languages. And I tried that, I did a Google translates, this sentence has seven words and then there were seven bits in the Japanese translation. I was like, "Cool, now I know this is seven words." And then I tried a bunch and then some word counter said there were three words and then others said there were 15 words. So I asked the help of someone I know that's a native Japanese speaker, and she said, "This sentence is eight words." So I was like, "Yeah, none of these work." Paul Mikulskis: Great. Kilian Valkhof: So I thought, we'll do everyone's favorite thing, we'll go to ChatGPT. So I gave ChatGPT the Japanese sentence, and I asked how many words are in there and it said, "There's eight words in there. These are the eight words." I was like, "Cool. Okay, so you understand this, now write me the JavaScript function that can parse this and tell me that there's eight words in the sentence." And it couldn't do that. It kept lying and writing this fake JavaScript- Paul Mikulskis: Yeah. What we're used to. Yep. Kilian Valkhof: ... saying like, "And if you console lock this, it'll console lock eight." And then you copy the code, and it said one. And it just kept doing that so I gave up. And to say, I have no CJK support for this feature when I launch it. I hope to at some point, but also there's a limit to what I know and what I can do. Yeah, that'll be something that I can improve in a future release. But it's also like, I expanded on the feature with the word count and the emoji counts, but I would never have come up with that specific feature myself. And I get feature requests like that all the time. Right now in Polypane, anything you do is synced between the panes. So not just scrolling but also clicking, typing, interacting with forms, but also hover effects. Paul Mikulskis: Oh, neat. Kilian Valkhof: So if you hover in one pane, the hover effects shows in all the other panes. That really speeds up your development time because you really only have to do QA in a single size and you get to do QA at all sizes at the same time. But initially, the first version of Polypane didn't have any syncing because at the time I was using a developer server with Browsersync built-in, and Browsersync already like the scroll syncing. And I naively thought, well, everyone that wants that will just use Browsersync. It's right there, you can install it. I thought it was super easy. And then literally the first feature request I got after releasing it was, "This is cool and all, but can you make it so that if I scroll in one that all the others also scroll." And I'm slowly learning and relearning that lesson that everything I think is obvious or that everyone knows isn't true and I can be way more helpful if I don't make those assumptions. So that's also why those features are in there. I'm sure a lot of users look at a lot of the features and think, I have no use for this, why is this in there, but then there's another group for who it's very useful, and that's the right mix. Paul Mikulskis: When you built a lot of your other projects, if you go to your personal website, Kilian, you can tell they've come out of a place of interest, passion, or need of, like we talked about earlier, not constantly saving something, and Polypane was similar as you hinted at. Do you find yourself coming into this new position in your head, like a new responsibility? Are you feeling any new responsibility with this bigger project? Do you feel more serious about Polypane with your other projects because this is a large undertaking, you have a large growing community of users and people interacting with it? Was this sort of like a turning point in your career as a developer and product designer? Kilian Valkhof: Yeah. So I started Polypane, the prototype scratched my own itch type thing in 2015, and I've been working on it full-time since 2019. So before that, I also built tons of apps and they're all like site projects, scratch my own itch, throw it out there. Polypane while using it, was really the first one where I noticed such a difference in just the time I spent building decreasing significantly, but at the same time, the quality of the work I was doing increasing noticeably that I was like, "There's really something here that I want to pursue." So yeah, I've been working on this full-time since 2019. Almost everything is user-driven based on user feedback iterated on with users. So yeah, it's definitely something I'm in for the long run. I always tell people, "When I launched my 1.0 in 2019, I had a roadmap of five years," and today I also have a roadmap of five years because there's just always more ways to improve it than there's time. Paul Mikulskis: And the web's always changing. Kilian Valkhof: Yeah, that's true. Yeah, there's always something new and interesting to add. Paul Mikulskis: Now, one of the poster child features coming out in version 13, Kilian, browser extensions. This is fitting because it just goes off of your "Why doesn't everybody just install a Browsersync?" Well, no, I'll just bake it in. This is kind of up the same alley, it's like let's bake in some functionality that maybe isn't completely necessary, but for me, having one password as a browser extension would be huge. Kilian Valkhof: Yeah. So actually people kept asking for specifically one password supports or Grammarly supports or a MetaMask support. And up till now for most things, I would just build my own thing, but I really didn't want to build a password vault. Doesn't sound like a clever thing to do on your own, so I didn't. Same goes for grammar stuff, same goes for crypto wallets. Whatever your stance is on that, you shouldn't try building one yourself. It really came to a point where people kept asking for these things that I never wanted to build myself, that I figured now's the time to start looking into supporting browser extensions because up till then, Polypane did support some developer tool extensions. If you use React, you had reactive tools. If you use Vue, you had the Vue dev tools. But browser extensions is a whole different thing because the developer tools were stuck in the Chromium dev tools, which are stuck to a single screen size because that's how Chromium dev tools work, they work with a single pane or a page. Whereas if you have browser extensions in the context of Polypane, you really expect that to work across everything. So I had to figure out how I could actually implement that and make it so that it doesn't matter in which pane you use one password, it'll just work. And then also Polypane is built in Electron, and that means that I have to rely on Electron support for browser extensions, which isn't a hundred percent of what's regular Chromium supports. So there's also just a limited subset of things I can realistically support in Polypane without rebuilding parts of Chromium, which also doesn't sound like a very clever thing to do. Paul Mikulskis: Yeah. What is a feature not related to the browser extensions that's coming out in 13 that you're personally excited about, that you think should have been in a previous version that you're only putting out now? Kilian Valkhof: So 13 is already out, and I would've loved to have done browser extensions earlier. But right now I'm working on 13.1 and that started out as what I was calling a me release. It was just going to be a release for me because I've been refactoring the build step from Webpack to Vite. Paul Mikulskis: Oh, beautiful. Kilian Valkhof: Because when I started Polypane, it was in 2015 and I was using Electron 0.29 and React 0.14, and Webpack. And then that Webpack configuration has just gone along with me from Webpack 2 to 3 to 4, to now 5. And unfortunately, with it, the build time has gone from 20 seconds, 30 seconds, one minute, one minute 30 seconds to if I now do yarn dev to start my Polypane development environment, it was taking two minutes for the apps to launch, which isn't really conductive to building. As far as this has to change. I need to switch over to something that's much faster. I tried switching over to Vite and it didn't work where it didn't properly work with some bits of Electron that I was using. And now I just made the decision, I'm just going to focus only on making the switch. So yeah, that's what [inaudible 00:29:45].1 is going to be. I did add that measure texting and some other neat features, but nothing super big. Now with Vite, my development startup time is back to 20 seconds. Paul Mikulskis: Love it. Kilian Valkhof: And that's amazing. I'm very happy with that. Paul Mikulskis: Isn't that cool? Congrats. That's awesome. Kilian Valkhof: Yeah. Paul Mikulskis: What does the team look like right now? Is it just you working on it Kilian or do you feel like you're really starting to build and nurture open-source hygiene or other creators and contributors coming to the code base? Kilian Valkhof: For now, it's just me. Before this, I used to run an internet agency, so I had people working for me. Right now, I still very much like having all the control and having all the accountability. What I usually say is: The bad thing is that when stuff is broken, it's my fault, but the good thing is that when stuff is broken, it's my fault and that means that I get to fix it regardless. And I don't have to wait on anyone to fix it or I don't have to figure out who's responsible or whatever. Now, it's always my fault and I always get to fix it, and that's great. That being said, I don't see myself working on this alone forever. At some point, it's going to make sense to bring in other developers, other team roles, but for now, I'm not there yet. Paul Mikulskis: Kilian, if people wanted to keep up to date with the latest Polypane updates or changes in the team, where would you urge people to go check-in. The Polypane homepage, I assume, is like a number one spot. Do you post on Twitter? Do you post on Medium? Does Polypane have a page? Kilian Valkhof: Yeah, twitter.com/polypane is where you can keep track of what's going on with Polypane. There's also a Slack group that you can join via the website, and I post more in-progress stuff there than I necessarily post on Twitter. So that's also if you want to give me feedback, please do. I'm happy with feedback literally anywhere, but in the Slack, it's easiest to iterate on stuff. So if you want to keep up to date with what's happening in Polypane right now, then join the Slack. And if you want to keep up with what's happening with Polypane and what will be in the new release, then twitter.com/polypane is the place to be. Paul Mikulskis: And for anybody listening that wants to keep up to date with Kilian and his projects, I mean the guy knows what he is doing. He wrote this tool that is re-implementing browsers and viewports, writing tons of different tools for the past decades. So keep up to date with Kilian. You can go to kilianvalkhof.com. Kilian Valkhof: Yeah, that works. Paul Mikulskis: And you can find personal projects. And Kilian, do you post on Twitter yourself on a personal page? Kilian Valkhof: Yeah. So that's twitter.com/kilianvalkhof. Again, it's a little Polypane heavy, but that's just because that's what I do all day every day. But I do post other stuff as well, and it's usually like nerdy HTML, CSS stuff that I hope you'll find interesting if you're listening to this podcast. Paul Mikulskis: Kilian, thank you for your time and for coming on talking to us about Polypane. I certainly have always been beholden to sort of like Chrome and the Chrome developer tools. And on a personal note, I'm excited to kind of see what is even possible with a different browser view of my websites, what could even be spawned that I wouldn't even think about from my productivity and my creativity. So thank you for coming on and for letting us pick your brain about Polypane. Kilian Valkhof: Yeah, thank you.