There should be a block called "value of key [] in browser". This would mean that you don't have to use the "find first" block.
Code:
Yeah I agree. I'll look into it, thanks for reminding me.
Update: I made a PR. It probably won't get in until 6.2.1 whenever that happens.
I've been using the database library and I think this block isn't quite right
I think it shouldn't return False if the key isn't found
I think it should return the same as the assoc block does when it doesn't find a matching value. e.g nothing/zero length string
But to compensate for this, I think there should be an explicit
Grump. Not at you, at all of us. We keep bouncing around about what to report when something isn't found in various contexts. When I first wrote FIND FIRST, it reported False, and I still think that's the best answer, but Jens didn't like it and made it report an empty string instead.
Part of the (design) problem is that Javascript has this value called Nil, and in the JS context that's what they return for any failure of a function. And Snap! renders JS Nil as an empty string. JS people don't see this as an issue to think about, because 0, False, Nil, and the empty string are all the same value and are interchangeable in JS code. But they're not interchangeable in Snap! and so long ago Jens picked the empty string, I guess partly because, following Scratch, in arithmetic operators we accept the empty string to mean 0, but in text operators 0 is different from the empty string.
Because I grew up in Logo, I pretty much never use empty strings in my own code. I don't think of text as a string of characters; I think of it as a sentence (represented as a list) made of words (nonempty text strings without spaces). The only use for an empty string in this approach is as the base case of a recursive function going through the letters of a word.
And the visual representation of an empty string doesn't shout out "string" to me; it's more like "nothing." But its type is Text.
Someday, maybe, we'll decide that every value other than False counts as true, so that we can do Scheme-style COND clauses of the form (expr -> function) meaning "if expr has a true value, return function(expr), otherwise go to the next clause." Then it'll be clear that False is the right answer for a failure of something like FIND FIRST. But I'm not holding my breath.
As a computer science teacher, I don't want my students to think that "returns an empty string" is the same as "returns nothing." Returning nothing is what command blocks do!
I think it should still return false in this case, because it's impossible to set a browser value to false, so you could easily know if it exists or not by checking if it's a boolean.
aah - so it is 
So I can live with the difference in behaviour compared to an assoc block