Day 211: Browserflow Everywhere

product

Of course, on the one day that I finally managed to get my butt outside and exercise before lunch, I end up poisoning my body with pollen and end up a sneezy, sniffling, fatigued mess with a foggy mind for the rest of the day even after taking antihistamines. Goodbye focus. Goodbye productivity. (Turns out it’s not much of a coincidence: I searched “allergies time of day” and learned that pollen count builds up in the morning and is highest around midday, which is surprise, surprise, when I went outside to work out. This is probably common knowledge, but given that these past few months have been my first time experiencing allergies, I’ve never paid much attention to this stuff.)

But today’s post isn’t about allergies. I resolved yesterday to spend some time this week thinking about * ~ The Future of Browserflow ~ * and so here we are.

Do you remember when you first learned about ad blockers? Maybe a friend tried to use your computer to show you a dope movie trailer on YouTube, but when you pulled it up, you had to wait for some dude to explain how he made MILLIONS off of flipping houses and how YOU CAN TOO. If your friend cared about you in the slightest, this is when they would’ve turned to you with a look of disgust and said, “dawg, you don’t use uBlock Origin? What is wrong with you.

I want Browserflow to be the ad blocker of productivity. When someone mentions how annoying it is that they can’t listen to music on YouTube without being constantly interrupted by the “Are you still watching?” popup or how they want to unfollow everyone on Twitter but don’t want to spend all day clicking through their list, I want the most common response to be “bruh, just use Browserflow”.

In today’s world, you need to hope that someone made a special browser extension for exactly the use case that you’re interested in (and then pray that they’re not harvesting and selling your data or will sell to someone who will sell your data) and even then, you’re out of luck if it doesn’t work exactly the way you want it to. But what if it were trivial to automate whatever you wanted?

Since Browserflow is basically a nice wrapper around JavaScript, I can see it being a gateway into programming in the same way that adding the dopest marquee to a MySpace/Geocities/Neopets page was for a lot of people. When building flows, the payoff is immediate because you can see experience the power of programming to save you time and energy.

A great example of a tool that’s accomplished this is Excel, or more broadly, the spreadsheet. The skill floor is extremely low — anyone can use a spreadsheet — but the skill ceiling is extremely high in that you can use macros and scripts to customize spreadsheets to run your entire business/life. I’m designing Browserflow with that approach in mind so that anyone can benefit from Browserflow, and if they take the time to learn how to use Browserflow to build custom flows, the possibilities become endless.

One of the challenges with a general purpose tool like Browserflow is that it’s initially hard to think of use cases. If you introduce spreadsheets to someone who’s never used one before, they might wonder what they would use it for. But once you start messing around with them and realize how useful it is for organizing data, you can use it to track everything including personal finances, sleep habits, survey responses, business metrics, etc.

This is why I believe that the key to Browserflow’s success will be answering “But what would I use this for?” Here’s how I imagine Browserflow will grow:

  1. Someone installs Browserflow to use a flow that solves a particular problem
  2. They discover other useful flows and start using Browserflow regularly
  3. They start building their own flows which other people would also find useful, which leads to more people installing Browserflow (step 1)

In a way, this is an evolution of userscripts except that by making it much, much easier to create flows, there will hopefully be many more people who are creating solutions that can be shared.

It’s clear to me that I need to build a Browserflow Store / Browserflow Gallery where people can discover useful flows as well as publish the ones they build so that others can use it.

There is, however, a major concern here: The Chrome extensions platform is adopting a set of changes called Manifest V3, and here’s one of the proposed changes:

Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) will still be allowed. This will help us better review the extensions uploaded, and keep our users safe. We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well).

I’m especially worried about this because depending on how this is interpreted, it can mean people won’t be able to share flows, or even worse, that Browserflow wouldn’t be approved in the first place. For example, in order to build the flow where I grab the timestamp from YouTube, I include some custom Javascript — would that not be allowed because that code wasn’t present in the extension’s package?

Thinking about this makes me question whether I’m being dumb by building on top of Chrome, where I’ve already seen that I can easily get burned. Oh man, I started off this post feeling excited and hopeful but the more I think about how all of my work can become instantly obsolete if the Chrome team decides it to be so, the more it seems like perhaps this is all headed towards heartbreak.