Although, forgoing "data-" prepending by default in the interest of saving a few bytes doesn't seem like a good tradeoff. If you have any HTML5 validation as part of your testing process, not having valid attributes is going to throw a whole mess of errors that you'll have to ignore.
Validation of your attributes is fairly meaningless, and if you have a decent validator setup as part of your workflow (save-time or build-time - I personally wouldn't bother with either), then you should be able to customise it to turn off silly errors. You could also pre-process your JS files as part of your build step to replace ng-* with data-ng-* if it really meant that much to you. The byte-saving doesn't matter of course, but it seems like extra typing and more repetition in your templates for zero benefit.
The problem is not whether a validator spits several errors or not, HTML validators are tools designed to point out stuff that is not conforming to the specs. It's stuff that you should avoid, not that will necessarily break your application on any web browser.
Why should you avoid it? Because, basically, if it's explicitly forbidden, or not covered by spec, you can't be sure of what will happen in all (or newer) browser implementations. If there's no defined behavior for some code, any behavior is correct.
Also, it's not like you have to go an extra mile in order to follow the specs here.
Btw, here's my point:
The reason, why you want valid html, is to be able to use some html validator, which is super helpful, when finding bugs like unclosed div etc.
However, if you prefix all the custom attributes with data-* you only get these attributes ignored, not validated. For example if you type data-ng-rrepeat="", the validator won't catch it.
So I would rather extend html validator to accept new tags/attributes in some format, say JSON, so that during the build process of your app, you can get all the directives your app defines and validate them. Then you get even your custom directives validated. I believe that's the way to go.
Small bug: the fixed-position "See Plans & Pricing" link that shows up at the bottom of the page when you scroll is partially hidden by the fixed-position "Talk to Us" link when the browser window is narrower than 1245px or so.
Crawlers, less so. The major search engines are getting smarter about it, but for now, you still need some kind of HTML output from the server if you really want to be indexed properly.
It doesn't rule out a pure client-side app at all, but you do have some extra work involved to output HTML from the server. Which is why NodeJS will ride on the coat-tails of this approach; less redundancy.
- When I click on an item thumbnail on your sample list page, it takes me directly to the image hosted on S3. Having the image appear in a lightbox would ensure that users are kept on the page.
- The title tag for every page reads "List of Things for Sale". I would populate the title tag with the name of the user (e.g. "Matthias McGregor's List of Things for Sale")
- Add FB/Twitter/Email to Friend links, which would provide three one-click marketing channels for users to share their for-sale items with their immediate network.
- Populate the page with Facebook Open Graph metadata. That way if users want to post a link to their store on Facebook, they'll get a nice link description and thumbnail automatically.
- I like the single-page experience, but I can't help wondering if it would be better if the app would generate discrete pages for each item users are selling. This might make it easier for users to share each item discretely, instead of just point people towards a single store page.