Would it be better to do a sepparate query instead of a left JOIN? Only a couple of rows is returned when not using LEFT since there isn't always data in the associated table - recipe_preparation. This is one of a couple of tables with the same "issue".

SELECT r.id, r.name,
    rp.explanation preparation,
    g.name
FROM recipes r
    LEFT JOIN recipes_preparation rp ON r.id = rp.fk_recipes_id AND rp.in_use = 1
    JOIN glassware g ON r.fk_glassware_id = g.id


The reason to why the preparation details is in a sepparate table is because of the ability to suggest/submit a better explanation. This is so the user can add their own/select a preffered one, and connect it to their account..
The AND rp.in_use is for the public one. 

Anyway; I've read somewhere that using LEFT is more expensive, and that it should be avoided if possible. I could query recipes and only JOIN glasses. Then, in my application, I could just do a new query on each recipes to check if there's any data to retrieve.

What would be the better solution?
and as I mentioned before; this is just one of several other tables with this "issue"..

UPDATE:
Here is a EER diagram that I'm working with:  



I've added a couple of more tables after this screenshoot was taken, and the in_use column in recipes_preparation (not indexed)..
Maybe this could tell a little more...

UPDATE #2:
I looked into the EXPLAIN statment, and this is the result I got - which didn't tell me much at first.


Looks like it starts with table g(glasses)? And it looks like it uses ALL as the join type - which is not good since that is a full table scan according to the MySQL Refrence..
Also; "MySQL found no index to use for executing the query more efficiently" more than? - the PK? - or non at all?
By your fine naming conventions I can take it that the fk_recipes_id column is indexed. This alone suggests that the query should be OK (pending cardinality of fk_recipes_id). If you further expand that index to include (fk_recipes_id, in_use), that would improve your query's execution plan.

Generally speaking, it is better to do a JOIN (including a LEFT one) within your database than to loop in your application code and submit multiple queries. 

I can't know for sure what goes on in your app; you should indeed just test it as @Jon suggests. With a large dataset I suspect you will see the difference very quickly (and it will be in favour of the database JOIN).