5 ms·

Not really "real time". See [2] (quoted below). `function update() { $("#live").load("/get_links/hot"); } setInterval(update, 10000);update();` Polling per se

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_events/Using_server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... [2] https://github.com/Max00355/HNLive/blob/master/templates/newest.html#L8 https://github.com/Max00355/HNLive/blob/master/templates/new...

andrewstuart2 11y ago
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 https://hacker-news.firebaseio.com/v0/topstories
- 2ton_jeff 11y ago
  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 11y ago
    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/#/newest http://insin.github.io/react-hn/#/newcomments http://insin.github.io/react-hn/#/newcomments
vanous 11y ago
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#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/EventSource...
- dspillett 11y ago
  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 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/ http://socket.io/ is probably the best know of these.
  - jondubois 11y ago
    No one cares about legacy browsers except you and your grandma ;p
    - dspillett 11y ago
      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.
  - 11y ago
jondubois 11y ago
I guess that explains why it's down right now :p

andrewstuart2 11y ago

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 https://hacker-news.firebaseio.com/v0/topstories

2ton_jeff 11y ago
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 11y ago
  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/#/newest http://insin.github.io/react-hn/#/newcomments http://insin.github.io/react-hn/#/newcomments

vanous 11y ago

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#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/EventSource...

dspillett 11y ago
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 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/ http://socket.io/ is probably the best know of these.
- jondubois 11y ago
  No one cares about legacy browsers except you and your grandma ;p
  - dspillett 11y ago
    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.
- 11y ago

jondubois 11y ago

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