Interview with Creator of Polypane, a Powerful Browser for Developers

Polypane is a powerful development web browser with many features to assist during the development of web applications and websites. Out of the box it immediately shows any website in several different dimensions, showing immediate value in reviewing the responsiveness of a website. That just scratches the surface of the features Polypane provides in improving the workflow for developing for the web.

We recently had the opportunity to sit down with Polypane creator Kilian Valkhof to learn more about what Polypane is, the motivation behind it, the technology used, challenges in creating the product, future direction, and much more.

InfoQ: I’ve been using Polypane as part of my development workflow for a bit, so thank you for that! Polypane is a really interesting product, a browser that streamlines portions of the modern web developer workflow by showing many different browser sizes simultaneously to help with responsive development, and also providing helpful features like previewing social media display of a site based on metadata. As the creator of Polypane, how did you first determine that you needed to create this product?

Kilian: Way back in 2015, I switched from Photoshop to using Sketch to design websites. One of the cool things that Sketch had was something called "Artboards", it let you design different screens (the artboards) on one huge canvas. The way I used it was to create an artboard for each responsive breakpoint of a site design side by side. That way you have a really great overview of your design at multiple screen sizes.

But then when I started implementing that design, my browser could only show a single viewport at a time and I was constantly resizing the browser or messing with the responsive design tools that were so slow. Compared to Sketch, it felt very limiting.

Around the same time I was playing around with Electron, a framework that lets you make desktop applications with web technologies. So I decided to make a little prototype that showed the same site in multiple widths. I started using it myself and quickly noticed it made me much faster, but also that there was so much more it could do. So I continued working on it as a side project until last year, when I decided to go full-time on it and develop it into a real product.

InfoQ: Could you tell us about the underlying technology of Polypane? You leverage Electron and its Chromium and Node.js-based foundation. What other interesting things have you leveraged to create Polypane?

Kilian: For Polypane, a nice benefit of it being built on Electron and Chromium is that I can leverage all the amazing hard work that Chromium has already done in their rendering engine.  It also means that the developer tools you're used to from Chrome 'just work' in Polypane (including devtools extensions like the React or Vuejs devtools). With Electron I can compile the application for MacOS, Windows and Linux, so developers can use it regardless of their preferred operating systems (I switch between all three).

The UI of Polypane is built in React. Most of the UI elements in Polypane tend to have such specific needs that I end up writing them myself rather than using an open source package. Nevertheless, the way React works fits really well with how I think about managing state in an application.

InfoQ: What are some of the main features and benefits of Polypane?

Kilian: Every feature in Polypane is focused on helping developers be either more productive, or build better websites and apps. The main thing is of course that it shows your site in multiple viewports. A lot of people initially compare that to "opening multiple windows" but it's really not: For one, you're not resizing any of the viewports. Polypane can automatically generate them from your CSS, or you can use the built-in device presets. So there is a lot less management.

InfoQ: Automatically generated from CSS, as in by reading media query dimensions or ?

Kilian: Exactly! Polypane reads out all the CSS that is applied to your page and analyses it. We use it to figure out which breakpoints your site uses, but also to apply hover effects in all viewports.

Secondly, everything you do in one viewport is replicated in all the others: scrolling, mouse hover effects, clicks and even keyboard input. So it's a really cohesive experience: you're interacting with a single website that just happens to be shown in multiple viewports at the same time.

Beyond that there are just tons of features that help developers.

There's built-in live reloading that can update CSS and images without a page refresh, even if you're not using any hot reloading support on your server. Actually, you don't even need to run a server, it works for plain ".html" files too.

There's full-page screenshots that work better than the screenshot feature in Chrome and Firefox (see here for a comparison), perfect for sending over to a customer or designer. Or to use in the image reference feature that we have, where you can overlay an image on top of the website, and then highlight the differences between them. Ideal to test against a screenshot of a previous version, or against a design reference.

InfoQ: Wow, so effectively a quick way to run simple visual regression comparisons or tests?

Kilian:  Yes! Highlighting differences will hide all parts of the page that are the same, and then highlight the differences so you can very quickly see if you accidentally moved some part of the page. If you're testing against a design it won't be exactly one-on-one, so Polypane also supports showing them side by side.

There's over 20 different "Overlays", which add functionality to a pane. For example there is a color contrast checker that tests your entire page for sufficient contrast between text color and background color. There's one that draws boxes around all elements so you can clearly see if everything is where you expect it to be. There's also a lot of different simulators, for color blindness and for other visual impairments. Things like Glaucoma and far-sightedness, but also bright sunlight. Some visual impairments have nothing to do with your eyes but might be situational.

The most recent addition to Polypane is the side panel. In it are tools that show you more info about the page, or let you edit it in new ways. The Live CSS editor lets you write CSS or SCSS that is applied to all panes. It can intelligently inject Google fonts if you use them, so it's a great way to experiment with your design. Using the element inspector in it, you can select an element and Polypane will get the actual CSS selectors from the CSS that apply to that element, so you can write CSS for that specific selector and then later copy it over to your own CSS files.

The Meta information panel shows you all sorts of information about the content of your page's <HEAD>, which usually gets overlooked because it's not visual. It will display things like your favicon, title and description, but it will also render pixel-perfect previews of how your page will look if it's shared on Twitter or Facebook, or how it will appear in Google search results. Testing this properly used to be very time consuming, since even though Twitter and Facebook have their own preview testers, they require your page to be online and they're not even up to date with the latest design!

InfoQ: Polypane isn’t the first attempt at a browser for web developers. For example, Blisk or Sizzy comes to mind. What are some of the key differences in your approach vs. that found in other browsers focused on web developers?

Kilian: I think one of the things that make Polypane so useful and expansive compared to other browsers for web developers is that, for the past 14 years, I was a web developer. I ran an internet agency and did design and development myself, as well as managed developers and designers. I also often interacted with developers or designers at our clients. Because of that I have a really broad view of what web designers and developers need to do, want to do, but also what gets overlooked a lot.

The features in Polypane are all things that I know are important for a broad range of developers. If you want to show a single mobile view and a large desktop view side by side, then you can do that. However while you do that you can also choose to zoom out the desktop view so that you can fit a 4k ultrawide on your 13" laptop screen alongside a 1:1 scale iPhone screen.

By using Polypane, you're no longer locked into only being able to develop for the devices you have. This works both ways: If all you have is a small laptop, you also get to make sure your site looks good on that 4K screen. But if you're a developer and only test on the fancy iPhone 11XS+ that you happen to have, Polypane lets you make sure that people that "only" have an iPhone SE also have a good experience. It gives you access to a device lab that is as expansive as you want it to be.

In Polypane, the viewports are not locked to devices either, they can be any size you want, a pretty big difference with other browsers out there. I think designing for devices specifically is the wrong optimization, and you can see that with websites that were built a few years ago that fit perfectly on 320px wide screens but look wrong on current mobile devices that are 375 or wider. And sites built for 375px wide are going to look wrong in a few years, when something else is the new default. Your websites will look better for longer if you pick breakpoints based on your content. That way, it'll look good regardless of how wide a screen happens to be.

Beyond that, no other browser that I know of is doing things like accessibility overlays or the social media previews. Those are things that as a developer you either already know and care about and use additional tooling for, or it just doesn't happen. By bringing those to the forefront I hope more developers get confronted with them, and that it will help them make better websites.

I want to make it easy to do things well, and I want to make it easy for developers to improve their own workflow. For example: if you're a SPA developer using React or Vue you might have a really solid hot reloading dev server, but if you're working on a more traditional Rails or Django app (which is just as valid a technology choice), then that shouldn't  mean you're not allowed to have really solid live reloading. By building that right into the browser, where you actually know a lot about the page, Polypane can do things like in-place updating of CSS without a single line of configuration written by the developer.

InfoQ: The Polypane website makes the claim that you can develop, debug, and test twice as fast? I would actually argue that for responsive issues it’s a lot more than twice as fast! What led to the claim of twice as fast?

Kilian: Haha, yeah so I have some statistics about that. The immediate speed up for a developer, so just how much faster an initial implementation is, is about a 60% reduction in time. But beyond that, because you've already developed and tested your site in so many screen sizes, you're going to have far less bugs and issues later on as the project goes through QA or after it has gone live.

Because those post-launch bugs don't come in, or if they do, far less often, it means that you no longer have to set up a project anew that you finished months ago, figure out how everything works, getting an up-to-date database and all these things. We've all been there where that stuff can take a full day to set up, only for the bug fix to be a single line of code somewhere.

For QA, if they do all their sizes testing in Polypane and then test on a few different rendering engines  and operating systems, it literally decimates the time they have to spend since even with orchestration, going through devices one by one (and keeping all of them up to date) is just a really slow process.

So yeah it's a lot more than twice as fast. However, developers are rightfully skeptical of claims like that, since they're often told that using such-and-such framework will make them super fast and will prevent them from ever writing bugs again but of course that's hardly ever true. So I ended up with "twice as fast" as a more plausible claim.

I think Polypane is like switching to a really good IDE or a code editor with intellisense. When you come upon it you might think "I already type really fast, how is this going to help?" but of course the speedup is in the typing you don't have to do. With Polypane, the speedup is in all the resizing, reloading and restarting of projects you don't have to do.

InfoQ: Is there a way to test Electron apps with Polypane?

Kilian: Polypane can display any HTML file, including one that you'd normally run in Electron directly, but of course your HTML file then doesn't have access to all the Electron libraries, so you could, but really only for the "website" part of an electron app.

In the same way you could use it to test for example Ionic applications that usually run in a native webview element. One of the cool things Polypane can do there is emulate both an iOS device and an Android device side-by-side, and Ionic will automatically render the appropriate styling in each viewport while you keep the synced interaction. That's going to be a lot more performant than running an ios and android emulator on your machine.

InfoQ: What are some of the interesting obstacles you’ve had to overcome in building Polypane?

Kilian: By far the biggest obstacle is that none of the existing browser tooling is built to support showing a site in multiple viewports simultaneously. The browser model is always one renderer = one site. Many internal browser APIs assume that and the devtools do too. While in Polypane you can have anything from 1 to a 100 renderers for a single site (though you better have plenty of RAM if you want to open a site in 100 viewports at once). So that creates new questions like "when is a page loaded?". Due to different resources that might be requested on different sizes, or just plain network fluctuations, different viewports are going to load faster than others. Is a page loaded when the first viewport is done, or when they're all done? It's a lot easier to answer if you just have one.

With Polypane, I have to build things from scratch each time, taking that into account. It's a lot of work but the benefit is that I can write features that are completely tailored to what I do in the browser. For example resizing a viewport in Polypane is much faster than resizing a pane in Chrome's responsive dev tools.

It also leads to some situations where Polypane is actually ahead of other browsers. Polypane has been able to show SVG favicons since at least 2017, but Chrome only recently got that ability.

InfoQ: What is your current web development toolchain and workflow of choice. What frameworks, libraries, and methodologies do you currently prefer?

Kilian: As I develop Polypane on my own I don't have a need for a lot of process, so planning and project management are done in Trello. I have the benefit of not needing sign-off from clients so rather than designing in a design tool, I usually design in HTML and CSS directly. My code editor of choice is Atom with a ton of custom keyboard shortcuts to make editing text as fast as typing. As I mentioned, Polypane is built in React, though it uses very little else of the React ecosystem since I end up writing most of the things myself. 

I've set up Polypane to automatically reload in development mode when I make changes. The two parts of Polypane (the Electron part and React part) run in their own process and then update independently.

InfoQ: (something like: With Polypane being built on open source technologies like Electron and React, do you contribute back to these projects or their community?)

Kilian: I have benefited from open source software a lot and I think it's an important part of the open web so whenever possible I try to contribute back though PRs or release things as open source. I'm a member of the Electron Governance team where I help out with documentation, the ecosystem and the website. For example, I wrote an entire document on the different options you have when you embed web content in Electron, something that comes directly from the experience I gained through building Polypane.

I maintain a few open source projects  that are interesting if you develop Electron applications. There's electron-to-chromium that adds Electron support to Browserslist (used by Babel and postCSS to provide the smallest possible transpiled JS and CSS), that one has over 15 million downloads a week, but you probably use that without even knowing. If you're building a cross-platform electron app with a menu, electron-create-menu lets you build a menu with convenience functions for multiplatform use and translations built in, so you don't have to build separate menus for different platforms or languages.

Whenever possible I try to contribute back improvements that I make to other libraries as I use them. For example I'm now working with VisBug to contribute some improvements to the way they display parts of their UI. In terms of other open source work I'm all over the place. I wrote a number of different desktop apps, like a note taking application that automatically saves and an image compression GUI, I made a PostCSS plugin that lets you write CSS in Dutch and a React renderer for Adobe XD.

Beyond open source work, I provide free resources for developers and designers. I build Superposition.design to let people extract design tokens from live websites that they can export to code or use directly in their design tools, and with Polypane I wrote a responsive design glossary and build a CSS selector specificity tool that explains your CSS selector and a color contrast checker that suggest better colors if needed.

InfoQ: For framework authors seeking to provide a robust developer experience with Polypane, beyond creating a Chrome DevTools extension, is there anything extra they can or should provide?

Kilian: One thing that I notice the most is that (library) developers tend to make assumptions about where code is run. The most obvious one is using the user agent. Polypane has a custom user agent and there are plenty of sites that flag Polypane because of that even though in terms of capabilities it's identical to Chrome. Using feature detection is the better option there.

I haven't encountered it yet, but all panes in Polypane share their session. This means you only have to log in once to be logged in everywhere (Or rather, you log in everywhere simultaneously) but it also means that localStorage and sessionStorage are synced between all panes. If you're a library and you store data in sessionStorage instead of in memory (for example, to make it easier to access in other parts of your library) that might be something to consider.

As the developer of Dojo you must have an interesting perspective on what you wish browsers do for you as a framework author. Anything you'd like to see browsers do?

InfoQ: As I think you’ll hear a lot of JavaScript developers lament, working with modern CSS layouts can be a challenge. There are many different ways to work with CSS, but it’s still often a challenge to visualize what’s actually happening with layout. Also I think there’s still quite a bit that could be done to better visualize what’s happening when debugging asynchronous code. And when working with Dojo and other frameworks like React which leverage JSX-based components, I think there’s a fair amount of introspection overhead that is challenging for new users to really understand what is happening in their application.

Kilian: Web development in general is definitely getting more complex. Even though the inspection and debugging tools we have for the web now are the best they've ever been, I think there are many ways browsers can help provide even more insight into what's happening.

InfoQ: We currently have a wide majority of browsers leveraging Chrome, with Firefox and Safari being the main alternatives today. What are your thoughts on the state of browser rendering engines

Kilian: We're at a point now where rendering engines are as complex as operating systems and in many ways they are operating systems. For developers, we've never had it as easy as now. I don't know about you, but I hardly ever have to think about cross-browser inconsistencies anymore between the existing rendering engines (and if I do, it's Safari), yet I still have a nearly encyclopedic knowledge of how IE8 can be made to behave.

InfoQ: Sadly I still waste space in my brain with Netscape 4 and IE 4 inconsistencies and document.layers vs. document.all.

Kilian: if there is ever an early-web edition of Trivial Pursuit I wouldn't want to play against you!  The danger is that a Chromium mono-culture stifles innovation. In some ways, you see that innovation has now gone up a level: it's no longer happening with competing rendering engines, but with competing browser implementations (Polypane being one of them).

I think the reality is that building a complete rendering engine for the web, with everything that that includes (html rendering, backward compatibility, webgl, wasm, device capabilities etc.) is by now only in reach for large companies. Maybe we'll see more specific rendering engines in the future, for example one that is really fast for wasm, or one that only renders modern SPA's that can be much faster because it doesn't support any of the legacy features.

InfoQ: There’s really nothing like Electron for Firefox or Safari, so I assume that a form of Polypane for those browsers is unlikely at best. Do you think Firefox can continue to thrive? (I hope so, I use Firefox as my primary browser of choice for viewing content!.)

Kilian: Firefox actually has a thing called "Geckoview", which is the Firefox rendering engine for Android. I'd love to be able to use Geckoview but it's not available for desktop. I've spoken to them about bringing Geckoview to desktop but from what I understood that's not planned.

For Safari/Webkit it's highly unlikely that they'll ever release a version of Webkit for Windows (again), let alone for Linux. And at this point other open source versions of Webkit like QtWebkit are so far removed from what Safari renders that it's not worth the effort.

Personally, I use Firefox as my browsing-browser too and have been doing that since it was called Phoenix. It's really good as a browsing-browser, even though they seem intent on making their browser less configurable and less powerful as time goes on, limiting what extensions can do and limiting the amount of UI customization you can do. I'm afraid that could hamper them in the future.

InfoQ: I’m also curious to see if another browser engine can actually get built given the significant complexity of supporting today’s web standards! The recent Flow announcement while light on details seems promising. Given that Safari’s WebKit itself was the original starting point for Chrome, which itself was a fork of KHTML, it’s been a really long time since we’ve had a truly new browser rendering engine, with the bigger trend being browsers like Opera and Edge putting their own engine aside to leverage Chromium. Putting on your crystal ball hat for a moment, what do you think the browser rendering engine landscape will look like in 5 years?

Kilian: A big fear is that rendering engine development will stop altogether like it did in the time of Internet Explorer 6, when Microsoft won the browser wars and had no incentive to further improve their browser. I don't think that will happen though.

What I do see as a potential danger is that the type of rendering engine development that will get done, and that will be adapted as a standard is going to weigh strongly in favor of what's good for Microsoft and Google (and to a lesser extent Samsung, which also uses Chromium). So things like AMP rather than improving HTML and CSS and more device-specific implementations (like device-based security implementations as used by Apple pay and Google pay) rather than maintaining an open web. Both Microsoft and Google have a varied history when it comes to this, having both been really strong proponents of the open web as well as strong detractors. Right now though, people at both companies are doing a lot of really good work for the open web.

InfoQ: Beyond the developer workflow improvements made already in Polypane, in what areas do you feel that browsers need to continue to evolve, not just for developers but for users in general?

Kilian: In the past few years the two things that for me have really changed the web are the rise of HTTPS thanks to Letsencrypt, and the widespread adoption of HTTP2.

These combined make the web faster and more secure, and I like that browsers are working on continuing that with HTTP3/QUIC and also by the intelligent blocking they've all started doing. The average web page has been growing steadily over the past decade but if you look outside of the US and Europe, prices for data are still exorbitantly high.

Better compression of resources and just simply downloading less cruft is going to make our experience in the west better and more secure, but in other parts of the world it's just plainly going to make the experience possible in the first place, without severely limiting what people can do like e.g. Opera mini does.

InfoQ: Shifting gears back to Polypane, what’s the out of the box experience like for getting started with Polypane. And what’s the pricing model for your service?

Kilian: Polypane is available for Mac, Windows and Linux so it's going to work regardless of what your preferred OS is. When you sign up for a trial you get to use it for 14 days before getting charged and you can download it straight away.

When you open Polypane for the first time and have authenticated the application, you fill in your domain name (or just use the getting started page) and you get to see that in multiple viewports immediately. This is when most people spot the first UI bug they overlooked.

At this point, Polypane has already gone through your CSS and found all the responsive breakpoints. It's interesting to check these out and see if you maybe have a few that are very near to each other: you could simplify your implementation by combining them. Have a look at the meta information panel to check if your site's info is what you expect it to be and at this point, you're off to the races.

Polypane is a monthly or yearly subscription, either for an individual developer at 12 dollars a month or 47 dollars a month for a 10-seat business license. If you get the yearly subscription a license is 20% cheaper. With this pricing it means that, if you save more than 5 minutes a month because you use Polypane, using Polypane makes you money.

InfoQ: What’s next on your roadmap for Polypane? Perhaps auto-generating perfect CSS by reading my mind?

Kilian: I have about 5 years worth of features written out that I want to add to Polypane, but I'm not sure that the neuralink feature is in there yet! In many ways it feels like I'm just getting started. I think Polypane can give you much more insight into what is happening with a web page. The meta information and social media previews are step one of that, and upcoming releases are going to improve on that by also giving warnings and suggestions. 

One of the most requested features is that people wish the devtools would synchronise between viewports. The Chromium devtools are not designed to support that in the slightest (believe me, I've checked) so I'm building an elements panel for Polypane. The first version of that is going to be in the upcoming release of Polypane. It gives a really quick overview of the element you selected. Like showing the box model, font information and if your text colors are readable. You can edit the CSS per selector like you're used to in the Chromium devtools, except they're applied to all viewports at the same time. Beyond that it's also really easy to edit the content of an element, the attributes and the dataset, all synced between all panes.

Between normal ("flow") layout, positioning, flexbox and grid it can become difficult to understand why your layout is the way it is. Polypane is going to get tools that make it easy to at a glance understand your element's layout.

A little further out, I want to really make it super easy for developers to find out if their site is configured optimally. When was the last time your browser told you all your internal links are missing a slash at the end, causing a 301 redirect?  That's a few ms slowdown every time someone clicks a link! I think showing that and highlighting that would be a great addition to Polypane, as well as things such as showing which resources don't have http compression like gzip or brotli, or have cache settings that are sub-optimal.

The main driver for me with Polypane is to make it easy for developers and designers to do the right thing in terms of making a fast, accessible and responsive website or web app. Web development is only going to get more complex as time goes on, and I want Polypane to help navigate that complexity. 

InfoQ: Thanks Kilian for taking the time to share your experience in building Polypane with InfoQ and our readers!

Kilian: Thanks Dylan, and to everyone reading this article for taking the time. If you have any questions, ask in the comments or visit Polypane to contact us directly.

About the Interviewee

Kilian Valkhof is a web developer and user experience developer with over 20 years of experience building things for the web. After running an internet agency for 14 years, he moved on to build tools that increase the productivity of web developers and designers and improve their workflow. Beyond that, Kilian writes about various topics, from design to machine learning on his personal website kilianvalkhof.com and is a frequent contributor to open source software.