December 29, 2007 at 14:01Flash vs Javascript. Reflections on Web applications.
Most recently, in the development of a project, my team faced the task of implementing an Internet application in which one of its components should not reboot when switching from one page to another. There were 2 options either to make a fully Flash application, or to use the implementation using iframe or object methods. Flash was dropped due to the technical requirements of porting the project to portable devices, so JavaScript and object remained. As a result, we settled on a diagram:
A container and two objects nested in it. Preliminary testing, the structure passed and we set about implementing
While browser developers did not realize that sites had long ceased to be a set of html pages, and more and more looked like applications, we (web developers) faced the difficult task of correctly functioning back and forth buttons with partial updating of content.
Our task is even more complicated by the fact that the actually updated page (content) is embedded in the container and even the content page is completely updated, the address bar does not change. And this deprives the user in the usual way of the opportunity to get a direct link to content within the site. By the usual way, I mean copying the address from the address bar.
When the list of problems was outlined, we began to look for solutions. And it was found in window.location.hash. I remembered that I saw how on one site it was somehow changed using JS methods, but I did not attach any importance to this. Later, when I did a search on my project, I finally realized that in the hash you can just write the very part of the link that usually goes after the domain name /. And that is exactly what we did.
Solving the problem with the current address bar gave rise to another. The Forward - Back buttons stopped working, because the only thing that changed in the address bar was hash. That is, in fact, the transition through history occurred, but the browser seeing that the URL did not change did not overload the content page. I had to hang up a timer, which once in half a second polled the address bar for changes and, if this happened, then overloaded the content. Through shamanism and JS-kung fu, performance was achieved in all popular browsers.
In the process of solving the navigation problem, we said goodbye to the XHTML-valid layout. Because the object tag, which we so successfully used instead of deprecated iframe, completely refused to give access to its parent window. Having spent a lot of time on shamanism, we said goodbye to the validator and inserted an iframe. In addition, IE gave a light and sneak on the topic of transparent PNG, inserting Flash and exporting its methods to JS. But these are trifles that are known to many and widely covered on the Internet, so I will not focus your attention on them.
By the way, SWFObject does not pass validation.
Initially, we could not refuse to use Flash. Then we would not have had an audio player and a multi-threaded bootloader. But instead of making visual elements on Flash, we made thin modules without an interface, allocating each living space in the size of 1x1 pixel. If you make them homeless, then in protest they stop exporting their methods to JS. We decided to put all the modules in a container and this allowed us to do a background load. That is, you can put files on the download and leave the download page, then return to it, and the files continue to be downloaded. (This mode is not yet included in the official release, since we are not sure of its stability.) In addition, by making thin modules, we minimized the number of JS <-> Flash joints and thereby increased the fault tolerance of the entire system. But then Safari said its decisive NO. The fact is that for some unknown reason, JS cannot pull Flash for its exported methods if they are in different frames. Fortunately, after the holidays, a MacBook will appear in our office for production purposes and we will overcome this browser.
The very first thing that turned out is that there is no perfect browser, everyone “breaks down” when you start driving them on the road off-road at top speed. Especially pleased IE with PNG, Opera, so that when you change the Opacity, it stubbornly imposes it on all the internal elements of the block, because of which the dissolution effect starts to slow down, and of course FireFox, which "switches like a grandmother" when processing JS. This is especially true for animation.
An attentive reader will ask me: “What does the headline have to do with the content?”
Now is the vacation, and there is time to think. So I'm sitting and I think it would not be easier to make a site on Flash. Despite all the charms that HTML + JS provides.
A container and two objects nested in it. Preliminary testing, the structure passed and we set about implementing
Chapter 1. AJAX versus browser-based navigation.
While browser developers did not realize that sites had long ceased to be a set of html pages, and more and more looked like applications, we (web developers) faced the difficult task of correctly functioning back and forth buttons with partial updating of content.
Our task is even more complicated by the fact that the actually updated page (content) is embedded in the container and even the content page is completely updated, the address bar does not change. And this deprives the user in the usual way of the opportunity to get a direct link to content within the site. By the usual way, I mean copying the address from the address bar.
When the list of problems was outlined, we began to look for solutions. And it was found in window.location.hash. I remembered that I saw how on one site it was somehow changed using JS methods, but I did not attach any importance to this. Later, when I did a search on my project, I finally realized that in the hash you can just write the very part of the link that usually goes after the domain name /. And that is exactly what we did.
Solving the problem with the current address bar gave rise to another. The Forward - Back buttons stopped working, because the only thing that changed in the address bar was hash. That is, in fact, the transition through history occurred, but the browser seeing that the URL did not change did not overload the content page. I had to hang up a timer, which once in half a second polled the address bar for changes and, if this happened, then overloaded the content. Through shamanism and JS-kung fu, performance was achieved in all popular browsers.
Chapter 2. IE again lowers from heaven to earth.
In the process of solving the navigation problem, we said goodbye to the XHTML-valid layout. Because the object tag, which we so successfully used instead of deprecated iframe, completely refused to give access to its parent window. Having spent a lot of time on shamanism, we said goodbye to the validator and inserted an iframe. In addition, IE gave a light and sneak on the topic of transparent PNG, inserting Flash and exporting its methods to JS. But these are trifles that are known to many and widely covered on the Internet, so I will not focus your attention on them.
By the way, SWFObject does not pass validation.
Chapter 3. And here is Flash
Initially, we could not refuse to use Flash. Then we would not have had an audio player and a multi-threaded bootloader. But instead of making visual elements on Flash, we made thin modules without an interface, allocating each living space in the size of 1x1 pixel. If you make them homeless, then in protest they stop exporting their methods to JS. We decided to put all the modules in a container and this allowed us to do a background load. That is, you can put files on the download and leave the download page, then return to it, and the files continue to be downloaded. (This mode is not yet included in the official release, since we are not sure of its stability.) In addition, by making thin modules, we minimized the number of JS <-> Flash joints and thereby increased the fault tolerance of the entire system. But then Safari said its decisive NO. The fact is that for some unknown reason, JS cannot pull Flash for its exported methods if they are in different frames. Fortunately, after the holidays, a MacBook will appear in our office for production purposes and we will overcome this browser.
Chapter 4. Today I understood a lot.
The very first thing that turned out is that there is no perfect browser, everyone “breaks down” when you start driving them on the road off-road at top speed. Especially pleased IE with PNG, Opera, so that when you change the Opacity, it stubbornly imposes it on all the internal elements of the block, because of which the dissolution effect starts to slow down, and of course FireFox, which "switches like a grandmother" when processing JS. This is especially true for animation.
Instead of a conclusion.
An attentive reader will ask me: “What does the headline have to do with the content?”
Now is the vacation, and there is time to think. So I'm sitting and I think it would not be easier to make a site on Flash. Despite all the charms that HTML + JS provides.