At first glance, the first option - a master-detail view, similar to desktop e-mail applications - seems more appropriate to this purpose. That master-detail paradigm however presupposes that, just as is the case with e-mail, the content of each message - or note, per your example - far exceeds the shorthand overview in the overview (or master) panel on the left - the 'grid', as you call it.
If you reasonably expect most notes to be 100s of lines long, I'd indeed opt for that master-detail scheme.
Consider what information you place into the mini-cards on the left panel. E-mail apps like Outlook often contain title, date received, and the first 80-or-so characters of the e-mails body text. For the purposes of a notes app however I'd give some thought to allowing users to type a shorthand summary of the respective note; a brief 'abstract' on what the note is all about to facilitate scanning and retrieval, without the need to click through each and every card to view hidden content.
However if you expect most notes to be brief, a flat all-in-one hierarchy may be better.
You could organise the info-architecture Twitter style (sort of), where each note entry now goes full-width across the frame, and has a set number of characters available for each note's body text. If that number is exceeded, don't cut your user off (as Twitter does) but instead, start hiding text off-frame. This should hit a compromise between displaying a certain number of notes in frame before scrolling, and showing acceptably long portions of text for each note. You could handle excess text by in-frame scrolling (like the text editor window on the Stack Exchange site which consistently displays 11-ish lines of text), or by truncating longer texts at the last line, with a More... link button to expand the note as needed. That does not block people from entering longer notes but encourages or even favours brevity in general.
