Day 269: git revert

product

spent a big chunk of time implementing a “break” command inside browserflow to let people break out of loops

after i got it working, i smiled and felt proud of myself. and then i realized i should probably get rid of it.

i added the break command because a few people have suggested it while trying out browserflow (including a friend from this morning). it exists in pretty much all programming languages, so why not, right?

the use case for a break command is to be able to stop the loop once some condition is met. for example, here’s a flow that prints 3 posts before stopping:

you start out with a count of 0, increase it for every post, and stop it once the count hits 3.

without the break command, the flow would go on until there were no more posts left. that’s highly problematic on sites with infinite feeds because surprise, there’s no end to posts.

but here’s what i realized, right after i’d spent all that time building the feature: a break command in browserflow is a bandaid for poor design. instead of requiring users to initialize a count, increase it for every post, and then check the count, why not let them indicate how many elements they want directly?

here’s what that flow would look like instead:

(i haven’t implemented it yet, but there would be a field inside the “loop elements” command where you can specify how many times you want to run the loop.)

so much cleaner.

and if people want to conditionally modify the number of iterations from inside the loop, they can use a variable for that. it’s the same idea as running:

// don't actually run this; it's an infinite loop and will choke ur browser 
// and yes i ran it and had my cpu explode in flames b/c i'm dumb
let limit = 5;
for (let i = 0; i < limit; i++) {
	console.log(i);
	limit++; // change number of iterations from inside the loop
}

it always sucks running git revert on work you JUST spent hours on but this is for the better. simpler interface = simpler product = happier users

notes to self:

  • before working on a feature, really think through what problem you want to solve before assuming that the first idea is the best solution

  • adding a feature is EXPENSIVE — once you add a command, it’ll be extremely hard to get rid of it if people are using it. in a normal product, deleting a feature most often just leads to complaints; on a platform, deleting a feature can break things much more severely.

  • do the right thing

    • for urself
    • for ur users
    • for the luv of browserflow