From my point of view, the key is not the amount of sprites that a virtual machine or a rendering output (example webgl) is capable of executing.
The main problem is the agility of development that allows the whole set of tools and language quality that a Flash type ecosystem provides. This does not exist in a web solution today, which means that the development times for interactive products are greater than in the past and therefore companies that work with short times, stop being competitive.
A simple example: in a similar development using Animate CC as a visual environment, if we export a "free" design (interactive design type tactile POI or educational product), the two fastest ways to solve a development are:
1) Flash (swf or AIR) GPU mode. No need to work with textures and much more agile in development than any webgl solution. The interactive seems fast and agile as the execution begins even on devices, with almost no need to optimize. You can convert vectors to bitmap at runtime in a complete solution without having to export and manage a lot of assets in different environments.
2) Animate CC HTML5 canvas output. The product is perceived as "heavy" just start the execution, (even if we convert vectors to bitmap). It can be optimized to a point but rarely gives the impression of being as agile or as smooth in execution as the first solution. Vectors in canvas are even much slower than in Flash Player. In devices it seems even heavier.
Both have the advantage of being able to use a combination of visual environment to place elements and a solid language when working. But the first solution is better out of the box (without having to do a lot of processes so that everything goes smoothly).
These differences are aggravated when there are a lot of totally different layout interactive screens. Different and complex designs in html5 canvas are very heavy and there are only two options. Load screens into another html (continuity is lost and gives the impression of patching) or through an intelligent loading system but it is too complex to develop, you could not use a visual environment to place elements, and it does not guarantee the same agility of a application based on swf's.
There are lots of web solutions and it is clear that a development can be more optimized in other types of canvas / webgl solutions like the ones you mention, but none is complete and all require more work than we had before. No matter where you look at it, what we have now has not improved, but worsened.
If the only variable needed to develop interactive products was "speed of execution", we all would develop everything in C ++, but this is unthinkable for the profitability of an interactive product company. The important thing is productivity (combined with a good and agile product obviously), but it seems a thing of the past.
In summary: It is not the result, but how and in what time of development you have reached that result.
All this is commented by someone with great development experience in: html5 (responsive dom + canvas), css3, javascript (+ different frameworks), asp, access, sql server, php, mysql, Flash, AS3, Director, Lingo, Unity, C # , etc.
The industry has simply been wrong (maybe because they doesn't give a shit about flash). But more important is that Adobe's shareholders have not wanted to risk. From my point of view in 2010 they had all the win with the very widespread technology, and in a position far superior to the html5 of then.
1 Correct answer
21
Replies
AdChoices