Author of Polypane here. I’m a bootstrapped solo dev trying to make this work :) Cool to finally see it on HN. If you have any questions, happy to answer them!
Maybe a bit of a weird question but I'm curious: What's the reason behind this being it's own entire browser? Like, if I were given the task of implementing this I would try to avoid creating a new browser (because it sounds like a lot of work). But I know that doing "weird things" like that sometimes causes you to hit a lot more roadblocks than expected and I'm curious to hear the technical story behind this!
I don't tend to think of forking Chromium as a new browser. I imagine that Chrome devtools aren't part of the browser extension API they provide, so creating something would have to start at a lower level.
They are on Firefox at least, I assume Chrome too, there's a Vue devtools extension for example that adds a tab alongside inspect, console, debugger, et al. to give you a sort of Vue-aware 'inspect'.
A browser extension would be the other option, but those are severely limited in what they can do and the regular browser model is not built with multiple panes in mind.
To do everything I want to do (like css media query breakpoint defection) I needed something more low-level.
If you’re still on their trial period, try Polypane as well and see which one you like better, that’s the quickest way to find out.
I think Polypane has more features but those can be copied (and are). With Polypane my goals is not to provide some fun tool, but to make you a better and more productive developer. More productive so you spend less time to get the same result, but better in that you’ll spend less time and end up with a more accessible and performant site.
So you’ll find a lot of features for things that are often overlooked and make those really easy to use, like accessibility tooling, or live reloading that works for any environment with zero configuration.
The latest addition in that area is that I wrote a completely custom element inspector that works across all panes at the same time and makes it really easy to edit styling and properties, live updated in all panes. It’s a joy to use and a major productivity boost.
Yeah I am often highly suspicious of these things saying "company X uses this!" - I've seen a few of those listing the Big Co where I had been working at the time was listed where it definitely was not in-use (and in one case the software was actually banned from expensing/licensing despite being listed on the vendor's site)
I use this as part of my daily workflow as a frontend developer. It saves me a ton of time instead of messing around with chrome windows. I prefer this over Sizzy because of frequent updates and better synchronized scroll support.
I do wish the reloading time would be faster but I understand that when you reload 7-10 chromium windows at the same time, it's bound to be a bit slow.
It does what it says on the tin, multiple Chromium panes at once with different dimensions, actions apparently sync up and everything. Frankly, I'm surprised nobody has thought of this sooner!
Multiplatform support for Windows/Mac/Linux, which is to be expected, given the Chromium base. Not open source, unfortunately, and free for trial only.
Firefox already has a Responsive Design Mode [0] that does this, but for one pane.
Combine that with a tiling window manager and you get everything except the pane
mirroring without having to use a proprietary browser.
I'd be interested in knowing if any other solutions exist just to add in the syncing
functionality.
Edit: a comment mentioned Browsersync [1]. Browsersync + a proper window manager should give you everything Polypane offers and more, with any browser.
BrowserSync[0] has syncing different tabs, reloading the page on code changes, layout mode, and many other features. It basically does what Polypane seems to do, and it's FOSS. The only thing missing is, as you mentioned, multiple windows side-by-side, and you can pretty much do that manually (or with a tiling WM - which you already mentioned).
browsersync is nice but it's just a different approach (proxying for multiple clients/tabs) with its own tradeoffs.
Polypane is one browser tab (1 debugger, 1 css editor, etc) with multiple viewports, so there's no extra hassle or window-management involved when inspecting an element, editing a style, hitting a breakpoint, etc.
All chromium browsers had this for a long time. The point is - nobody really provided a feature to have N views with different resolutions for the same source
browsersync syncs up everything, so I'm sort of failing to see the difference between this and a few tiled windows side by side (what I currently do) with browsersync sync'ing scrolling and clicking. You're likely already using it as part of your webpack dev flow anyways.
This is maybe the 7th take on this multi-viewport browser in the past few years. Is there some hidden business model I'm missing to justify the number of similar projects?
I'm wondering about the business side of this. This tool sounds useful, but I bet that Mozilla could implement this quite easily if the market wants this, so why would a company pour resources into building something like this?
And as a user, I would probably miss the developer tools.
There’s both support for chromium devtools (including devtools extensions) and I just launched a new custom Element inspector that’s even more convenient. What would you miss?
Same. I'd rather be without than paying another subscription. I have to vote with my wallet, it's the only way i can influence the situation. Subscriptions create lock-in and dependence. Just sell the product and charge for big updates.
General question for the HN crowd: If one is passionate about building dev tools then what's a good path for monetization? The options seem so very limited. Fixed prices are nowhere near enough to cover the costs of supporting a complex app and paying for 50+ subscription services doesn't make sense for developers either. So far all I've seen is what effectively amounts to sponsorships by FAANG type companies to build OSS dev tools.
I make a great living selling Cursive (https://cursive-ide.com). I use perpetual licensing with a year of updates, $99 for personal and $199 for commercial licences. Renewing for more updates initially costs half that and then goes up linearly to 75% over the first year after update period expiry. I also have a free non-commercial licence for OSS work/student work/personal hacking.
I figured that I would sell about the same number of personal and commercial licences since there are still a lot of hobbyists dabbling with Clojure, but in the end the vast majority of my sales and revenue are commercial licences. Most of my revenue is new licence sales, but I see a fair number of renewals too.
Short answer: a good path for monetization is just charging for your work. It's kind of old fashioned but it does work, even for dev tools. If your product solves a real problem companies are willing to pay to make the problem go away, especially if your product is more polished than the (presumably OSS) alternatives.
That's true, but in my opinion unless there's actually some active on-going service, just charge for new versions and/or maintenance. This whole saturation of everyone charging everyone $10/month is tiring and frustratingly expensive as they know most will not pause or meter their billing in periods of inactivity.
There's still examples of software developers charging for software. For example, https://www.just-great-software.com only sells their software, they don't even charge for new versions or updates most of the time nowadays.
Yes it may not make a fortune, but with some ad-buying maintenance, upgrades, etc. there's likely an okay business.
The problem is every second developer is also passionate about building dev tools. The market is naturally over-saturated.
The world does not need more dev tools.
There are bountiful real-world problems out there itching to be solved with software for the developer who can overcome their one-dimensional interests, to stop harbouring in the safe waters of the abstract and embrace the real world. Take up a hobby as distinct from programming as you can tolerate. Instead of that next industry meetup, go give a hand in your local community.
If you build a tool, I will buy it. If you keep improving it, then sell the update. Sometimes I like the product and do not have the cashflow to upgrade, so I will do it later.
I think it would be fairly clear to me whether I like it within a week. Since it’s not a hugely expensive subscription, paying for one month isn’t really the problem either.
Anyone else find it painful scrolling through that site and waiting for the animations to reveal the next "block"?
They're smooth, but by the time they show up my eyes have moved on from the void where they had expected content to be. Coupled with the "marketingy" phrases it annoyed me enough to leave before I learned anything about what makes this browser special.
As a developer myself there’s a constant struggle regarding how marketingy I should make it. I don’t think I’m making any over-the-top claims and there’s no denying it works, but different people respond to different things.
I'd love to hear the details of why web developers like this feature? As opposed to say, clicking through the various dimensions in the responsive design mode? I guess the idea is seeing the changes live: So as you're fixing one aspect ratio, make sure you're not simultaneously breaking another?
If you're using something like Webpack, that supports hot reloading, couldn't you simulate this just by having multiple browser windows open, each displaying a different dimension size? So then is the idea that having to set that up manually each time is a pain?
(Not judging, just seeking to understand, I'm a huge fan of any kind of speed increase, but I'm curious if I'm missing anything here.)
Thanks! Follow-up question: So I'm guessing a "component library viewer" is a local web app that you run to view WIP/finished components (like for https://storybook.js.org/)? If you have a link to an example I'd love to check it out.
