[lambdacomplete]

Not really "real time". See [2] (quoted below).

`function update() { $("#live").load("/get_links/hot"); } setInterval(update, 10000);update();`

Polling per se is ok but you should do it on the server and push to the client through web sockets or server-sent events [1].

Refs:

[1] https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

[2] https://github.com/Max00355/HNLive/blob/master/templates/new...

[andrewstuart2]

Especially when there's a fancy fully-real-time API provided for free by firebase. Not that it's the most efficient way to query all the top stories, but there's plenty that can be done with it.

https://hacker-news.firebaseio.com/v0/topstories

[2ton_jeff]

when I wrote hnwatch last year, there were some "issues" with the firebase feed, but for the most part the firebaseio goods are in fact realtime.

[insin]

It works pretty well, but there are still some "issues" you need to deal with:

- Items for users with a delay configured get posted to the API before their content is made available (if you go to the story id on HN proper, there's a * placeholder)

- The odd item will come back as `null` from the API for a while

As long as you deal going from not having content for an item to having content in an update, the API usually corrects itself eventually.

Here are live feeds of new stories and comments from the Firebase API in the client I wrote when it was announced:

http://insin.github.io/react-hn/#/newest

http://insin.github.io/react-hn/#/newcomments

[vanous]

Thanks for the links. Any experiences with practical deployment, the compatibility chart [1] shows minimal support for mobile browsers and no support for IE? I have several command line tools that i expose via internal web pages and ended up also using setInterval based polling, rather then server pushed messaging.

[1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource...

[dspillett]

For supporting legacy browsers you need to fall back to polling unfortunately.

A better option than repeated requests every X seconds (or X times per second) is long polling (see https://en.wikipedia.org/wiki/Push_technology for brief notes and your preferred search engine for many examples). You can only do this if you control the back-end (so can dictate its API) or the API you are using explicitly supports long polling, of course.

There are a number of libraries out there that try to wrap the different methods into one so you don't have to worry about compatibility, using the more efficient websockets where possible, falling back to long-poll where not, and sometimes other methods in between (integrating a little bit of flash for instance). http://socket.io/ is probably the best know of these.

[mchahn]

Server-sent-events are an often overlooked alternative to polling and websockets. They work on all browsers and I'm having good luck using them.

[dspillett]

I thought that got dropped from "HTML5" and was considered deprecated?

It was never implemented directly in IE or Edge (http://caniuse.com/#feat=eventsource), so when you say "work in all browsers" do you discount IE or can you recommend a good well-supported polyfill?

[jondubois]

No one cares about legacy browsers except you and your grandma ;p

[dspillett]

He specifically mentioned compatibility charts, which implies he isn't just looking at supporting the latest and greatest!

In my personal projects I don't care about legacy browsers (to users that far out of date I say "please go be a pain in the side for someone else"), but professionally I'll have to support at least as far back as IE8 for a while yet and I suspect a great many people are in the same position.

[jondubois]

I guess that explains why it's down right now :p