My main concern is immediacy. There's 0 setup time, and you can instantly share your work. Especially for (relatively) novice programmers, being able to immediately link to something someone more pro can see is invaluable.
I deliberately left dabblet out because command + shift + left (the shortcut programmed into my brain for 'select this entire line') closes the editor. Annoying as hell.
This post is talking about prototypes from a usability perspective, not a technical perspective. A prototype by your definition ( a "real" prototype) would use data and be built in about the same way as the final product would be. I'm talking about how to prototype the experience. I see how it's easy for you to misunderstand me - apologies for not being clear.
Then it would be helpful if you qualify prototype as "ux prototype" or "interaction prototype". Paper prototypes, which this is fairly similar to, is a term that is lexically unambiguous. Without the qualification the title becomes confusing. I initially thought you were claiming to have a methodology to get a "real" non trivial prototype in a few hours.
Your post mixes together wireframing with prototype hacking. But I guess this is to be expected when programmers are doing design, a designer would look at this very differently.
That's accurate, and I think that's all the more reason to jump in and start. The content is all there, but there's more detail needed to make an app like this awesome, including stats and UX polish. I'm advocating for the 'just start' approach.
