Persistant Chat Window? Like Facebook or OkCupid - ajax

I saw this question asked here 18 months ago, but without (a correct) answer: Window like facebook chat
Both Facebook and OkCupid have messaging windows which stay open even when you click to another page on their website. Literally the IM window (and friend list, on Facebook) don't so much as flash or "blink" as if they were reloading quickly. If you refresh the website (F5 or such) then the messages will disappear, at least for a moment.
The only thing I can think of is that the entire website never actually changes addresses, but just pushes the new URLs to your browser so it looks like the URL changed, but you never really left the same file.
How are they offering this persistent chat?

My guess is they are using something similar to qjuery-pjax:
https://github.com/defunkt/jquery-pjax
From their docs:
pjax works by grabbing html from your server via ajax and replacing the content of a container on your page with the ajax'd html. It then updates the browser's current url using pushState without reloading your page's layout or any resources (js, css), giving the appearance of a fast, full page load. But really it's just ajax and pushState.
This means clicking a link on the page will load only part for page and leave the chat windows untouched (no flicker). If you hit F5, the browser is initiating the refresh which will not use ajax/pushState. This causes the chat windows to flicker.

Related

What are full page reloads and Why did we need to do full page reloads without ajax?

I was reading up on ajax and how it empowers us to exchange data with a server behind the scenes and consequently avoid full page reloads. My confusion lies here, I don't really understand what full-page reloads mean. I think it's probably cause I've been working with ajax/react since the start I guess and have not really seen any webpage of mine fully reload when I access stuff from a database or an api.
It'd be great if someone could explain what they are and why did we need them before ajax?
A full page load is where the entire page is downloaded from the server. A page typically consists of several sections: header, footer, navigation, and content. In a classic web application without AJAX, a user clicks on a link to another page, and has to download the full page, even though only the main content is changing. The header, footer, and navigation all get downloaded again even though they don't change.
With AJAX there is the opportunity to only change the parts of the page that will change. When a user clicks on the link, JavaScript loads just the content for that link and inserts it into the current page. The header, footer, and navigation don't need to reload.
This introduces other problems that need attention.
When AJAX inserts new content into the page, the URL doesn't change. That makes it difficult for users to bookmark or link to specific content. Well written AJAX applications use history.pushState() to update the URL when loading content via AJAX.
There are then two paths to get to every piece of content. Users can either load the URL containing that content directly, or load the content into some other page by following a link. Web developers need to test and ensure both work.
Search engines have trouble crawling AJAX powered sites. For best compatibility, you need to employ server side rendering (SSR) or pre-rendering to serve initial content on a page load that doesn't require JavaScript.
Even for Googlebot (which executes JavaScript) care must be taken to make an AJAX powered site crawlable. Googlebot doesn't simulate user actions like clicking, scrolling, hovering, or moving the mouse.
Content needs to appear on page load without any user interaction
You must use <a href=...> links for navigation so that Googlebot can find other pages by scanning the document object model (DOM). For users, JavaScript can intercept clicks on those links and prevent a full page load by using return false from the onclick handler or event.preventDefault() in the click handler.

Loading a website without browser showing spinning wheel

I am just curious to know how these websites were made to load only once. If you go to the sites http://fueled.com/ or http://ecap.co.nz/, the browser shows the spinning wheel only the first time the website is loaded. When you navigate to other pages from the navigation menu, like About or Contact or Team, when those pages load, the browser doesn't show the spinning wheel.
How do they make them work like this?
It is because page load is not triggered upon those links. Instead, a post request is triggered and its response will be used. Also, further page loads will be quicker, since scripts, styles and pictures will be cached, that is, saved locally on your computer.
You can check what happens using the browser console's network tab. Click on the last request before you click on such a link. You will see that the request log will not be cleared, but other requests are added. That means there is no page load in the meantime.

Too many FB share button request

I'm optimizing my site speed. One of the main issue I'm facing is the homepage.
In the homepage, each article has FB/TW share buttons.
I only inserted the scripts in the footer once but I'm getting bunch of FB/TW share button requests.
Is it normal or there is something I need to do?
For every Like/Share button that you have, your browser needs to make a request to get the content. This is only executed when the browser has received the page from your server, so it does not affect the initial load time.
As CBroe mentions, the button is displayed in an iFrame. These are loaded and depending on your browser settings all at the same time or consecutive. During this time, your browser is not blocked so your used can already interact with the page.
If you want to reduce load, the only option is to remove the buttons. I think you have some index/home page where you load all the articles and for each of those a button? You could consider only showing the buttons on the articles itself, if you are really concerned about this.
But, since this is normal behaviour and your page is not blocked by loading all the iframes, this is not a big issue nor can you optimise it yourself.

Implement Ajax to keep background animation at same place throughout all pages

I was wondering what the best way to keep my background.asp file playing throughout all of my web pages.
My website www.marioplanet.com uses ASP #includes in order to keep certain parts of my website the same. So, if I want to change a link in my header, I just need to update 1 file.
Now, I was wondering how to keep my background.asp file loaded throughout my entire site, which has all of my music functionality, even when changing pages.
Therefore, the music and backgrounds are continuous throughout the entire site.
How can I most easily do this without restructuring my entire site? Or would I have to completely redo my site?
From what I understand, you're looking for a way to keep track of the state of e.g. a music player while your visitor is navigating around on your site.
The following ideas might help:
Make your entire website an AJAX application where state is given through hash identifiers (take a look at Facebook and the jQuery History Forward plugin). With this you could start playing music and the user would navigate around the site without reloading the entire page (hence, without stopping the music).
Set a cookie with the timestamp of when the music player starts (via Javascript). Now, when a page loads, check for the existence of such a cookie and, if returned, calculate the offset between cookie timestamp and current timestamp. Setting the player to that offset will pick up the music approximately where it stopped on the last page.
Control the music in a separate pop-up window. Old fashioned and not really nice in terms of usability.
Control the music in an invisible frame that doesn't reload. Very old fashioned and with major backlashes for the user (there is a reason why traditional frames are out-dated).
Hope this helps. :)
If I understand you correctly, you are essentially wanting to have the background and music (which can be loaded in the background) never reload once the user visits the site. THe best way to do this is to make the site a completely AJAX based application, and use jQuery to load pages into divs when the user is navigating through the site.
Essentially you will want to create an index page which holds your backgound, and also contains a 'content' div. When a user clicks on a navigation button using the jQuery .load() method to load the requested page into the content div.
Another option is to go with jQuery UI, and have an element like their tabs component where you define all of the different pages of the site, and then it takes care of all the heavy lifting for you.
There are a few tutorials around for using jQuery with ASP.Net. I would definately go with it while trying to do something like this.

Web page expired message in browser

I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.

Resources