[Html 5] SharedWorker Case Studies
In Html 5, a whole zoo of features has already been bred, and, I think, there are already few people who know the whole "Html 5" completely. I think less than a percent of you have heard about some SharedWorkers.
This is a kind of session, only on the client. And in addition, not just a session as a repository, but a session as a living process.
You can use them to communicate between the tabs of the same site.
Also, I believe, now a website can be considered modern only if it has the so-called “push”: pushing updates from the server directly to the browser to the client. In order to implement such a push, you need to establish a WebSocket connection on the page. At the same time, each tab of your site will create its own connection via WebSocket.
This increases the load on the server, and the connection itself takes some time (for me in Chrome it takes about a couple of seconds on Node.js on localhost). We can try to reduce the load by making sure that all the tabs in the client browser use the same common WebSocket connection. And these SharedWorkers will help us with this.
The other day, I somehow figured out how this all works (which is complicated by the fact that you can’t make such a “debug” a simple alert: it can easily fail to start if it doesn’t like something, and even swears). To simplify the work with this thing, I wrote a library - shared worker.js .
Next to it, you can see a simple example of implementing communication between tabs (example folder) and an example of push implementation (websocket example folder). In Chrome, all examples run only from under the web server; just opening them from the hard drive will not work (such a flaw in Chrome; an ajax to local files in Chrome will also fail). An example with web sockets requires the execution of the
Works in Chrome and Opera. It does not work in Firefox. More details .
When I tried to google this topic, nothing was found. I also did not find any normal examples ( the only one that was found , to put it mildly, is dirty, and there is not a word about “include” in it, without which you can’t write a real application - just an academic example). Now, searchers can find it on Google.
In this case, you will need to write navigation on the site on ajax (for example, how Vkontakte did it), because if you, for example, open a tab with the site, and in it just go to another page of the same site using the regular link, then the current SharedWorker is destroyed and a new one is created. This is logical: when you switch to a new Url, even on the same site, the page you are redirecting to is destroyed first, and only then the page you are redirecting to is created.
There is a “connect” event in the current Api SharedWorker, but there is no “disconnect” event, and therefore the peers array in the shared worker.js library cannot self-clear closed tabs - it will continue to consider them open. This will not lead to any errors, it’s just a flaw in the current Api SharedWorker.
What is it?
This is a kind of session, only on the client. And in addition, not just a session as a repository, but a session as a living process.
Why might this be needed?
You can use them to communicate between the tabs of the same site.
Also, I believe, now a website can be considered modern only if it has the so-called “push”: pushing updates from the server directly to the browser to the client. In order to implement such a push, you need to establish a WebSocket connection on the page. At the same time, each tab of your site will create its own connection via WebSocket.
This increases the load on the server, and the connection itself takes some time (for me in Chrome it takes about a couple of seconds on Node.js on localhost). We can try to reduce the load by making sure that all the tabs in the client browser use the same common WebSocket connection. And these SharedWorkers will help us with this.
How it works?
The other day, I somehow figured out how this all works (which is complicated by the fact that you can’t make such a “debug” a simple alert: it can easily fail to start if it doesn’t like something, and even swears). To simplify the work with this thing, I wrote a library - shared worker.js .
Next to it, you can see a simple example of implementing communication between tabs (example folder) and an example of push implementation (websocket example folder). In Chrome, all examples run only from under the web server; just opening them from the hard drive will not work (such a flaw in Chrome; an ajax to local files in Chrome will also fail). An example with web sockets requires the execution of the
npm install ws
and commands node server.js
.Where does it work?
Works in Chrome and Opera. It does not work in Firefox. More details .
What is so little?
When I tried to google this topic, nothing was found. I also did not find any normal examples ( the only one that was found , to put it mildly, is dirty, and there is not a word about “include” in it, without which you can’t write a real application - just an academic example). Now, searchers can find it on Google.
More about links
In this case, you will need to write navigation on the site on ajax (for example, how Vkontakte did it), because if you, for example, open a tab with the site, and in it just go to another page of the same site using the regular link, then the current SharedWorker is destroyed and a new one is created. This is logical: when you switch to a new Url, even on the same site, the page you are redirecting to is destroyed first, and only then the page you are redirecting to is created.
Disadvantages of Api
There is a “connect” event in the current Api SharedWorker, but there is no “disconnect” event, and therefore the peers array in the shared worker.js library cannot self-clear closed tabs - it will continue to consider them open. This will not lead to any errors, it’s just a flaw in the current Api SharedWorker.