Really helpful to see how a successful team builds apps end to end.
My most recent experience has me leaning towards spending the time to wireframe though. Ryan warns against this as a waste of time "building higher fidelity sketches" (than paper), but to me building a sketch in omnigraffle is much faster than on paper, and it can be easier to convey more complicated user interactions as you can copy and paste etc. Also, for more interactive components of a UI, showing interactions through a wireframe is much much faster than prototyping it in javascript, so it becomes worth it to quickly validate that the interactive UI makes sense (by sharing the wireframes with a few people) before diving into the code (the simple example he had wouldn't really warrant a more interactive UI, but imagine, say, designing mint.com's transaction browsing / management / tagging app). That process might last a few extra hours, but if it saves you from building a snazzy UI that doesn't make sense, time well spent.
Personally I like the Wacom Tablet as an alternative to paper sketching. You get (almost) the immediacy of paper with the benefits of copy / paste, layers, undo, erase, etc
Personally I do high fidelity right away. I want to get as close to the final product as possible which includes the actual flow between the clicks.
The wireframe step is fine if you are dealing with client's and don't want to get into the aesthetic discussion before you have started working on it (believe me you wont). But more often than not it's a wast of time.
I agree that you shouldn't waste time, but I think wireframing is an important and necessary step that shouldn't be avoided or underestimated.
When you go right into high fidelity prototyping you are focusing on many elements of the design simultaneously. You are focusing on the coding (html prototypes), visual design, information architecture (layout, navigation, etc) and you are doing it all at once.
Because of this you end up giving each department bits and pieces of attention, but not enough to see all the details and insights had you focused entirely on each department one-by-one.
I've shot right to hi-fi mockups before and I ended up not seeing a crucial insight in the information architecture side of the project. For me, doing low-fi wireframes and then moving to hi-fi mockups works much better, so I don't overlook certain details and insights.
My most recent experience has me leaning towards spending the time to wireframe though. Ryan warns against this as a waste of time "building higher fidelity sketches" (than paper), but to me building a sketch in omnigraffle is much faster than on paper, and it can be easier to convey more complicated user interactions as you can copy and paste etc. Also, for more interactive components of a UI, showing interactions through a wireframe is much much faster than prototyping it in javascript, so it becomes worth it to quickly validate that the interactive UI makes sense (by sharing the wireframes with a few people) before diving into the code (the simple example he had wouldn't really warrant a more interactive UI, but imagine, say, designing mint.com's transaction browsing / management / tagging app). That process might last a few extra hours, but if it saves you from building a snazzy UI that doesn't make sense, time well spent.