Synchronizing Website (DOM) on multiple devices - javascript

I need to invent a method to synchronize multiple devices that are connected to a Website.
Lets say I have a Tablet and a Laptop and change some elements of the dom on the laptop. Then the
website on the Tablet should change accordingly.
At first I need a way to monitor the dom changes. I read a lot in forums and have also tried to work with browser-synch (https://github.com/shakyShane/browser-sync) but it does not monitor all events. However it may happen that the websites are not in synch.
I have also tried to use the new MutationServer techniques. But I am not sure how exactly to update the websites on the other devices:
In case a new node has been added to the DOM I first have to determine its position inside the tree; then send all the informations to the other clients (i guess via nodejs and socketio). The clients have to put the newly created node in the right position of their tree.
In case a node has been edited or removed I have to react on it as well...
So my question is: Do you have any ideas or literature to solve my problem?
I just need some good hints to start because I am not really sure which method leads me to the "best" solution. I want to invent an efficient solution as well.
Sure, I could monitor the DOM by checking x times in a second whether changes occured. But this method is not really efficient especially not for mobile devices.
Hope you guys can help me and lead me to the right direction.
Best regards.

note: There is nothing ready and this is not so simple to do.
Capture all DOM maybe this will help you: AcID DOM Inspector
Capture "event Listeners" use Visual Event 2
Avoid capture frames (or use them) because security issues (cross-origin) may occur.
In my view it is not necessary to capture the entire document, it would only be necessary to capture inserts the "BODY" and "HEAD"
And avoid complex structures, perhaps the events (eventslistiners) need not be captured, only you would need to have a library that adds already existing events. Unless the events are created by customers, in which case you will have to capture them.
To transmit them you have to use Ajax and shared with DataBase (SQLServer, Mysql, MongoDB, etc).
From my point of view:
If you want to create is an application just to share data, for example someone posted a "new photo" or a "new comment", would be better to make the transmission of which was inserted in the "database" for "JSON" and clients read the "JSON" your main "javascript library" would dynamically generate the contents.
Thus would transmit much less making things faster and easier to implement process.

Related

How to reliably reconstruct the DOM in real-time to do co-browsing (mirroring webpage usage)

There are some SaaS tools [1, 2] that give you a plugin to run on your site, so that you can view how your users are interacting with your website remotely.
I'm guessing this works by streaming DOM updates back to a remote server, but I'm not sure of that. I'm really interested in how this technology works, and whether or not there are tools out there to do similar tasks.
Here's the question: How do they do it? How can we reliably "co-browse" through the use of an installed Javascript snippet? I know of some solutions using WebRTC, but the browser support doesn't seem to be there yet
This is known as session replay.
I'm guessing this works by streaming DOM updates back to a remote server
No, it probably doesn't care about DOM updates. The script would capture every single input event, including key presses, mouse moves, mouse clicks, scroll events etc. Those are what UX designers are usually care about when evaluating their page design. They also might capture the initial state of the DOM.
If those plugins are just for data acquisition (like in A/B tests), I don't think the plugin scripts do actually live-stream those events. It probably captures them, stores them in some compressed data structure, and sends it to the service provider when the user leaves the page or in regular intervals.
Live streaming would certainly be possible, and it seems to be that this is what that co-browsing plugin does. (There's apparently also a back channel - a huge security risk! - to trigger mouse clicks etc remotely). WebRTC (which also could feed the complete video) might one approach, but a web socket would be enough.
Some documentation on how togetherjs in particular does it can be found at https://togetherjs.com/docs/#technology-overview.

Simple push server for prototyping

I want to make a live prototype to demonstrate transactions between two users in different browsers. It should keep the state of the UI in sync between two sessions when each user performs an action. For instance: when one user presses purchase in one browser window, the other user should see that the item is marked as sold in another.
There's nothing new about this, except that I need the absolute minimum solution to fake this behaviour in order to be able to iterate quickly to optimize the flow before starting the actual implementation.
I was thinking Flux and React, or maybe node, but I'm completely new to these frameworks.
Does anyone here have a good suggestion to the best way of approaching this without ending up building a full application? Or maybe to direct me to good starting points?
My suggestion is a NodeJS-ExpressJS-SocketIO combination solution.
It might sound scary if you don't have experience with any of those, but SocketIO is one of the libraries I usually describe as magic.
Just look at the example of the SocketIO website (which already includes everything to run) example instructions and the code of the example
I never used react so I can't say anything on how simple it is to do using it. but the big magic here is actually SocketIO. it might be usable inside react.

Communicating two or more browser tabs, which could be the best method?

I want to design a small (at least, the very basics for now) IDE to make websites and applications with HTML, CSS, Javascript and a full LAMP stack.
One of the things I would like to do is to be able to open the preview window in a different browser tab (instead of having it in an HTML-encoded tab (a <div> element or similar), like Dreamweaver does) or even, while in source mode, being able to display the toolset in another browser tab and displace this tab onto a second display (or even a third one, although I have just one display, but it's for illustrating my situation).
Once deployed in another browser tab, I want for every browser tab to reflect any changes done to any of the other browser tabs.
For example, if I have the source view in one display and open the properties grid in another and I change a color input value, I want the output view to reflect this change in color for whichever component gets the update.
I have my mind quite clear on how to approach the data structures, how to do the preview, data caching, storing the project data, etc.
What I don't have that clear is how to effectively communicate the tabs between them. One idea is to use a combination of AJAX requests and server-sent events (SSEs) to communicate but, even if that could work, looks like crude to me.
I was thinking on something like websockets with message passing. I could encode any changes in a given component, send them to the server and have it route to the appropiate listeners for each one of them to reflect any change locally.
I have very litte experience with websockets, though... so I'm in doubt. Can you give me a hint on what could be the most efficient method here?
I've experimented recently with WebSockets, in combination Java on Server and JavaScript on client side. First wanted to go with simple Java SE, had a nightmare, didn't succeed to make it work and at end the found this tutorial:
https://blog.idrsolutions.com/2013/12/websockets-an-introduction/
Works like charm. Just stick with environment mentioned there - Java EE, GlassFish, NetBeans... Not saying that NetBeans is best IDE or something...
Of course, there is NodeJS option for back-end if you preffer JavaScript.
But generally speaking WebSockets works...and works well. :)

Getting multiple pages talking to each other

I am coding a Web app that needs to have multiple tabs/Web pages open. And I would like them to talk to each other. And I don't want the pages to talk to the server. So is it possible with HTML5/JS? By the way they are all on the same domain name.
I've never come across a webapp which used the browsers tab functionality as a means of navigating. I don't want to say it's wrong, because I don't know your particular requirements and, of course, I haven't played with every single webapp in the world.
However, would it not make more sense to implement your own tabbing system within your web app than rely on a feature of the browser which is probably inconsistently implemented and which may be affected by the user's personal settings?
If you're set on this path, and offline functionality is a definite requirement, then I think your only option is using the LocalConnection feature of Flash, as Brad suggests in the comments. I imagine you could create a bridge with ExternalInterface to pass any data from Flash to the page. The Flash would need do nothing else but marshal the communications (it could occupy a single pixel somewhere on the page). This is a similar approach to the one the dojotookit took with their Flash storage, designed to provide a more capable alternative to cookies.
I think the answer here is that what happens in the view, doesn't have to reveal whats happening behind the scenes.
You can make DOM elements on a page communicate with other DOM elements on the page without making a asynchronous call to the server if thats what you're asking.
If you have two tabs in the.. lets say chrome browser, and you want one DOM element to talk to another DOM element on a completely different browser tab. You have to make that asynchronous call to the server which will shoot one back to the other tab. But you don't have to show that happening in the view :) (This can be done with Node.JS/Socket.io, an example would be a chat room built with HTML5/JS)
Hope this helps
I know this is an older post, but you may want to look into local storage, or even cookies set via javascript.
There are 2 reliable ways you can have pages in other tabs (or across iframes) talk to each other.
The postMessage API allows pages to send messages even when they are on different domains. There are some security issues to be aware of to avoid malicious behavior. You can read about that in the linked article.
localStorage and sessionStorage will dispatch a "storage" event when they are changed. Using this event you can be notified in other tabs when the data has changed. This only works within the same domain. Because this is all you need, it might be the wiser option to avoid any security issues.

HTML/Javascript system for many different popups and widgets in the same page

I'm making a HTML5 page (game) which uses lot of popups and all kind of widgets appearing and dissapearing in the same page.
To implement this I could
Have all the popups and widgets listed in the page, invisible (like lot of examples I saw), and keep toggling only visibility.
Add and remove dynamically, using Javascript. I could put each popup as HTML fragment in a separate file (?).
The seconds is "modular" and I like the fact that I have no elements in the page which I'm not acutally using. But I don't know about performance (load HTML each time, DOM insertiong, etc.).
Is there a prefered/standard way to do this?
If we are talking about loading HTML from server, then obviously this won't be efficient.
I don't know what kind of game you are writing but I don't think there will be any visible difference in performance (except for loading data from server) unless you create like thousands popups per second (I doubt it). Let's be honest - your game isn't using like 4GB of memory. :) And if it is, then you're probably doing something wrong. And I do not think there is any standard way. It's more like how you feel it. :)
For example I always try to load every possible data from server with one request and store it on client-side, because most problems with performance is actually related to client-server communication. I also like the DOM to be clean, so in most cases I hold the (hidden) data in JavaScript, except for forms' hidden fields.
On the other hand, if I have for example blog with discussion and I load some additional data (for example user data, which is supposed to appear as a popup after click on the user's name) I tend to store it in DOM elements because it is easier (at least for me) to control it (I'm talking about jQuery and jQuery UI).
Note that it is possible that recreating popups may lead to memory leaks, but it is highly unlikely if you use some popular library like (for example) jQuery UI.

Categories