We Keep Coding

How to implement push notification cross-browser?

I have a web application and I need the user to be able to see wether a notification for them has landed. I want the notification icon to change it's state when they have a new one.
Basically, I want to listen when the API endpoint updates it's state for the current user and the front end to change it's state.
I thought of make that endpoint as an observable and the front end as an observer, but I don't know if that fits in what I need.
Any ideas?

I'd suggest to use a web socket implementation, such as Socket.io.
Although there are many alternatives to Socket.io, its major advantage is that it provides multiple fallbacks for older browsers. So, e.g. if web sockets are not available or do not work, it tries AJAX long polling. This way you can even support browsers that were created at a time, when nobody even knew what web sockets are - but to you, the API stays the same.
If you know that you only have to deal with modern browsers, you may use a more lightweight alternative instead, e.g. ws.
If you are looking for something completely different, which is purely based on HTTP and does not require an additional protocol, you might be interested in HTML5 Server-sent events. They work great, but in contrast to web sockets they are not bidirectional, and they are currently not supported in IE and Edge. They also have some other disadvantages. For example, it's not possible to add custom headers to an SSE request.
With HTTP2 it's maybe questionable how much impact web sockets will still have in the future, especially if you take into account that things such as the Streams API are coming. Then, you could basically solve everything using pure HTTP, which has some advantages as well. But right now, the Streams API is not here, so let's wait and see…

SSE or WebSockets for Stackoverflow-like instant notification

What is the best technology to use if I want to make instant user notification,
like StackOverflow has?
I consider SSE and WebSockets. What are pros and cons of each solution?
Should I use socket.io or better to use WebSockets directly?

The main difference is that with SSE you can only receive messages from the server. You cannot send messages to the server. Everything doable with SSE is doable with WebSockets. But not vice versa - WebSocket is capable of sending data to the server. So from that point of view WebSockets win. I can't really see any advantage of SSE (perhaps performance?), but then again I don't have much experience with it.
Note that StackOverflow uses WebSockets. They might have some fallback for older browser, I don't know about that.
As for the third question: perhaps you should ask what language you want to use in the first place? I've been working with WebSockets and Python and it worked really well. You could work with WebSockets directly. The advantage of using socket.io is mostly the fallback (assuming it matters - it does not IMHO): if WebSockets are not available it can automatically switch to other ways of communication (like Flash or long polling). The disadvantage is that it is Node.js (in the sense that you have to restrict yourself to one language) plus there are some performance issues, i.e. socket.io does not scale well beyond one machine.

You might consider using a library like SocketIO that abstracts out the transport layer, so you don't have to worry about the mechanics of how the real-time connection is maintained. This will save you a TON of headaches.

How do websites instantly update their content using AJAX?

Today, when I was using Google+ in two separate browsers, I posted something with one browser. The post almost instantly appeared on the second browser (there was maybe 0.5 seconds of delay). How does Google achieve this? Do they constantly send AJax requests to check for new posts? Wouldn't this put a lot of strain on the server?

There are a variety of methods can be used to do this:
Websockets
AJAX Long-Polling
page timers
iframes
Each one has it's own caveats and possibilities.
If you're interested in being able to do a real-time application, you might have a look at socket.io which is a great abstraction library for all of these technologies, so it'll use the one which is best supported in your browser.

Can't say how Google does it exactly for sure, but they would have to be using some sort of push technology. HTML5 WebSockets is something that can do this in newer browsers. In older browsers that don't support websockets, the client usually polls the server periodically. See socket.io for a neat cross-browser implementation of WebSockets, with fallbacks to other methods if the browser doesn't support it, documented here.

I suppose one technique they could use is to send an AJAX request immediately and then block it on the server side until a timeout or content is available to be sent.

For years google was using Comet or Reverse Ajax: http://en.wikipedia.org/wiki/Comet_(programming))
However, I believe they are using HTML5 WebSocket now that the API is ready:
http://en.wikipedia.org/wiki/WebSocket/
http://dev.w3.org/html5/websockets/

Real-time bi-directional JSON-RPC communication over HTTP

I am building a JSON-RPC server that accepts requests over HTTP. I would like to support bi-directional communication (both client and server can send requests), the specific use case being a publish/subscribe architecture where a client sends a subscribe(X) request and receives changed(X) requests in (almost) real-time. As far as I know, there are several ways to implement this with HTTP:
long polling
WebSockets
polling calls using a cookie-based session model
streaming (keeping the HTTP connection open)
a combination of some of the above
What I'm looking for is a solution that is based on accepted internet standards (if possible), usable from a web browser and easy to work with on the client side. So far, I favour the streaming thing (Twitter, CouchDB do it that way), but I'm not sure about how well this is supported within browsers and JSON-RPC libraries. Also, there may be other ways to do it that I'm not aware of.
Thank you in advance.

I think you should have a look at socket.io to accomplish your task. You could if you wanted to watch this video from the author: "Socket.IO Workshop: Guillermo Rauch". It is easy to work with on both server as client. I have created a simple sample pubsub using redis on top of socket.io.

To my knowledge, Streaming is supported by FF, Chrome (Has bufffering issues that require a datatype of application/octet-stream or a prelude to work) and IE8 (through a little XDomainRequest). I don't know about opera.
I don't really know of any comet industry standards, the Bayeux is probably the closest. It's hard to see how facebook/gmail/twitter do it as all the code is obfuscated, and it's exceedingly difficult to find much info on how all the browsers handle everything.
Even more difficult is that you will need to use a specialized server, keeping this many connections open will require thread pooling etc.. A normal server will blow up pretty fast.
It is a very powerful design if you can get it to work reliably though.

You should take a look at JSONRPC-bidirectional.It supports bidirectional RPC over WebSocket, Worker, WebRTC and HTTP and it is highly extensible.

If anyone is interested in a Java implementation I just wrote a sample app and a blog post about it. It uses Java, Maven, Comet, Bayeux, Spring.
http://jaye.felipera.cloudbees.net/
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo

Web Sockets questions

I have a couple of questions concerning Web Sockets.
The latest Firefox 4.0 nightlies support Web Sockets. So does Webkit (Chrome 4 + Safari 4/5). Internet Explorer 9 is supposed to feature Web Sockets at some point according to Microsoft (before the stable release).
Anyway, my questions are:
I am building a JavaScript admin interface to manage a website. Should I use Web Sockets for the client-server communication instead of XMLHttpRequest if I told you that I do not need to care about browser compatibility?
Would Web Sockets result in faster save, deletion and update calls compared to the usual situation with XMLHttpRequest? Would the requests be more instant?
I am aware of the HTML5's navigator.online and window.addEventListener('offline', ...), but with Web Sockets (upon connection loss), am I able to detect connection issues more accurately and faster? I mean, when I turn off my Internet connection, or block it with my firewall, Firefox still seems to state that navigator.online is true. With Web Sockets, it seems, the connection to the server will be lost instantly, thus, I can detect connection problems more accurately?
Can I support Web Sockets server-side with pure PHP, so, that the code is portable with other web servers (no need to install any Apache modules or do other customization). I would like to distribute the software to a couple of places without having to ask people to install all sorts of modules to their HTTPD or so.
I wish you can answer to as many of those questions as possible. I am really interested in answers.

I am building a JavaScript admin interface to manage a website. Should I use Web Sockets for the client-server communication instead of XMLHttpRequest if I told you that I do not need to care about browser compatibility?
It appears to me that you want to use WebSockets just for the sake of it. The main reason to use WebSockets is when you want to push data from the server to the client. If your application does not need this, you should probably not use WebSockets.
Would Web Sockets result in faster save, deletion and update calls compared to the usual situation with XMLHttpRequest? Would the requests be more instant?
You could probably save some time on both ends (client and server) due to the absence of headers. But the gain is probably pretty small.
with Web Sockets (upon connection loss), am I able to detect connection issues more accurately and faster?
Yes, an event will fire instantly when the WebSocket closes. Alternatives would be long-polling or periodic XHRs. Or event client-side storage.
Can I support Web Sockets server-side with pure PHP, so, that the code is portable with other web servers
First I suggest you read through this. WebSockets don't work very well in a synchronous way. PHP and apache don't work very well in an asynchronous way. Although there are some implementations, many of them are outdated. I personally would use an other language for this, such as ruby, python, java or server-side javascript. Simply because the languages have better support for the asynchronous model and the WebSocket implementations are more sophisticated.
The WebSocket protocol is currently still a draft, it can change. Just like it did a few weeks ago. So your code may very well break.
My advice is: Do not use WebSockets just for the sake of it. If you have a real-time event-driven application, then it is probably the right choice. Make sure you understand what WebSockets are for and what it takes on the server side, also in terms of event-driven applications. Don't use it for anything production, it's way too fragile.