I started on this Tuesday after work. Because of some great APIs that are available, it really came together quickly. Most of the credit goes to this one in particular:
Really great. One piece of feedback: Clicking on text works great but you can't use the browser back button to get back to the overview. That means you have to reload the page after every click on text.
ihackernews is great but I feel there is many bugs when it comes to comments. I use the Hacker News app for android created by Jazzy Chad which is great but the ihackernews api for comments always fails to load. I wish there was a fix for this.
Nice work. I work in mobile web and I applaud the simplicity and speed. That said, to really make it snappy, bind to 'touchstart' instead of 'click' --- or implement a 'tap' event.
Also, I might go a couple font sizes larger. It's readable, but small on my phone.
All in all though, it's pretty nice. It's a good example of what mobile web can do and showcases the power of client side development when you have an API to support it.
You can steal most of this stuff out of jqm, if you grab the events and vmouse plugins. Month's worth of work to speed up clicks and simplify the way you bind to events in the page.
[edit] jbail means to say there's a 200ms (or so) delay from touchstart to when click is fired in mobile browsers. He's obviously relatively experienced with mobile web dev :)
Thanks -- I just made some changes and iOS and Android are now firing on touchstart. Additionally I cut the slide in animation time by 50%. It feels much snappier!
I also added a back button so it can more easily be run fullscreen.
keep in mind touchstart is fired in swipes as well so binding to touchstart only could have unintended consequences. Like I said there's a lot to consider when it comes to solving the click issue on mobile.
Which phone out of curiosity? I was actually thinking of knocking the font size down a bit! There must be some inconsistency I can fix.
It's fast because I didn't both with a mobile web framework. I've found those (especially jQuery mobile with its DOM caching) to perform horribly. This should scroll as quickly and smoothly as your phone can.
...and you're totally right about jQuery Mobile causing suckage. I used it for a couple features and I'm now ripping it out in favor of a little handrolled solution I built. I even replaced the jQuery core library with XUI because it's even smaller has most of the goodies I use 99% of the time.
For everything XUI doesn't have, I really like XUI.extends in its simplicity better than the jQuery plugin architecture. Super easy to add whatever else you need.
I'm using the new webkit browser and the back button works fine for me, as does the rest of the site - great work! Opera mini doesn't work for me though, just stays stuck on Loading. I noticed someone with Android mentioning the same thing so I think it's an Opera specific thing, not BB.
Looks great, I'll try it out. I've been using iHackernews.com for awhile and to my knowledge pretty much every other hacker news app out there uses their api as well. They had a problem where they were always having 502 errors when you clicked on comments for a post for awhile, but this seems to have been fixed in the last couple of weeks or something.
I wrote the server-side portion of this app. It's actually a tiny coffee script program that caches iHN.net's API calls in redis. We cache/proxy the successful responses and toss out the 500s. When a cached copy of the content is available it'll be served immediately from redis. We refresh the cache on-demand in the background. This allows us to buffer out delayed / erroneous 500 errors the iHN API sometimes responds with.
This is running on a 256mb Ubuntu virtual server and it's overkill for both processor and memory. Kind of neat watching the story climb HN (currently #4) and watching `top` without being able to tell anything is happening on the server at all: 0,0,0,0%user,100%idle -- a testament to the light weight beauty of node,redis,nginx.
I don't use the iHackerNews API for news:yc. It seemed too unreliable to use a third party service that seemed to keep having issues, and I didn't want user data to go through a third party. But I think it's cool to easily create a HN app without rewriting the scraping.
I scrape inside the app using a combination of libxml2, a custom XML wrapper for iOS, and then a horribly ugly (but pretty adaptable) chunk of objective-c to parse out the contents. This helps mostly for rate limiting issues: each device is rate limited as it should be.
I've been working on a HN-esque design for a non HN site and had taken a similar approach with using favicons as this variant does. I think the icons really help and also assist with identification (of, say, TechCrunch articles.. whether you do or don't want to read them). What do people make of their use in this project?
I don't like 'em in this usage, because imo they just add to the Matthew Effect of recognized stuff getting more recognized (http://en.wikipedia.org/wiki/Matthew_effect_(sociology)). I'd personally prefer an option to completely filter out domains I don't want results from, and then no visual differentiation among the rest.
How do you resolve favicons? Browsers are very resilient at finding favicons. Websites can use meta refreshes, variants on <link rel="..."> tags, domain.com/favicon.{ico,png}, gzipped images, and inserting icon elements with javascript. You could also use parent domains if you don't have a favicon for a subdomain.
Writing your own favicon-getter is by contrast... kind of annoying.
I love them! It helps with scanning the front page. Due to the location/fact that it is text/text colour I never look at the URL of an article when looking at the front page on news.ycombinator.com.
Very nice. I read HN from my iPhone a lot, and it's mobile version would be very handy.
However, using this, I quickly realised that original design has some advantages (though, maybe it is just habit issues). Usually I scan frontpage fast for new highrated entries to read first, and having 10 entries on screen in time is more suited for this. With 4 it's just another experience. I feel that I need more time to find something interesting.
Maybe you can improve this, for example, indicating rating with color or size of rating digits.
Rats! There has been an Error. This application depends on a number of external APIs, sometimes they don't always work. When this happens, your best bet is to reload.
Nice. I created something like this that was text-only back in my Blackberry days, but when I switched to Android and jQueryMobile came out I enhanced my site to its current state: http://webbindustries.com/cgi-bin/myfeeds.cgi
It's old school: perl mirroring the RSS feed and writing out simple html markup for jQueryMobile to format. It supports a bunch of other feeds too (I used to read more than just HN this way) and it switches to a nice multi-column format on larger devices.
I was going to post one concurrently -- but I thought it would be more interesting to see how the server-side cache held up under load. We're grabbing some screens while this is the top post and will include that information.
The client-side bit of the post will be interesting mostly in that it's not interesting. By keeping things basic, this was easy and performs well.
I especially like the textual version of the link. This will be helpful on my mobile device, where I pay for connectivity, loading only what is important is great.
Works great in the stock Android browser, but it's stuck on "Loading" in Opera on Android. Then again . . Opera on Android seems to mess up every other site.
No because they can't make cross-domain ajax calls. And they can't make requests on behalf of very many people on their server without hammering the HN server. Even if they were willing to ask for people's passwords.
http://api.ihackernews.com/
It's all JS/client-side templating. Ask any questions if you have them. It works great as a Shortcut app on the iPhone.
edit: Lots of requests for a back button -- I'll be sure to add that!