I think you hit the API Limit. Just fixed a bug that used an old API key for API calls (got lower limits).
Big chance you won't get that error if you retry it after 10 minutes (time needed for Amazon Cloudfront to push the new version to all the edge locations).
However Scrolldit is (most of the time) a pure timewaster, check this:
377.913 (unique visits) x 1.20 (avg minutes on the site) = 453495,6 minutes = an impact of 314,93 wasted days on our world economy.
However with all those minutes wasted I felt the need to do something productive, I think Scrollsy.com is a good try.
Supporting all those small shopkeepers, trying to give them more exposure.
Multiple things: I love endless scrolling and visually rich designs, I want to learn new techniques and ofcourse it's great to see other people using these mashups. Btw this mashup was also some kind of compensation for the damage I've done with http://Scrolldit.com
I think the most important thing is that the loading animation be anchored to the bottom of the loaded content so that it never obscures content that's already loaded. If the user manages to outrace your loader and gets to the bottom, some kind of indication that the app is churning away would no doubt be welcome.
You can try throwing a 'position: fixed; bottom: 21px;' on your #loading div instead of positioning w/ JS.
Also, the animation on the items isn't very smooth and I find it distracting. It'll probably feel smoother without the drop down animation (maybe a quick $.fadeIn) might look good.
When I did an Etsy app, there was no affiliate program, which seemed to largely stem from the fact that Etsy charged to little to sellers that they were barely making a profit. The idea of giving a cut to ousters seemed like a bad idea. I'm not sure if it's changed. But when one considers the number of Etsy apps that have been made just for the joy of it, it would seem to be in Etsy's favor to incentivize developers once they can get the numbers to work out.
You really should have a fallback page for browsers with no Javascript. NoScript has become increasing popular and the "Javscript Free" page of a site is the first page those users will see (even if they go on to temporarily allow javascript for your app).
In your case, it is just a blank white page. Since you are asking for suggestions, I would suggest you just make it display a message. One for suggesting users with older browsers to download chrome or firefox and another message directed at those with Javascript intentionally disabled which gives a very brief outline of what your app does and why they should enable JS to play with it.
e: I clicked through to the other mashups you have created which you linked in your other comment. They all do the same thing, just bring me to a blank page.
ee: To those down-voting, what do you disagree with? Do you not think pure JS web apps should have HTML fallback pages or do you disagree with the way I said it?
I didn't downvote you but I personally never worry about users with JavaScript disabled, and the companies I have worked for don't care either. The number of people without JavaScript is most likely way to low to spend time on an HTML fallback.
An adequate "fallback" is <noscript><p class='something_nice'>This site requires Javascript to function</p></noscript>. It's not exactly hard, and it's better than a blank white page.
It can also occur due to network problems on occasion or other technical issues; if you have JS beyond just progressive enhancement on your site you really ought to have a <noscript> tag in there somewhere.
It's a fair argument that overall percentage is low, but if you are catering towards a more technical audience (submitting to HN would count as that in my books) then I imagine the % of those using some form of Javascript blocking software is much higher.
Plus as mentioned, it isn't like it takes much effort, a noscript tag and a paragraph saying that it is a pure JS web app/what it does is enough.
Showing a 'Please activate javascript' message is indeed a good idea. A complete HTML only fallback is impossible since everything happens in the browser (JSONP API calls).
Big chance you won't get that error if you retry it after 10 minutes (time needed for Amazon Cloudfront to push the new version to all the edge locations).