Flash or Canvas?

Question

JavaScript

Friends, I need your advice. I have been writing a turn-based strategy for a long time , and it so happened historically that the client is written in HTML + JS / jQuery. Everything would be fine, but people demand to make big cards , and here the wild brakes begin. 20000 DIVs and these are only tiles with almost no troops, and already the DOM is serious. Even scrolling slows down, not to mention animations and calculations of possible paths.

I would like to carefully transfer all this to a faster technology, but where? Flash, Canvas? I didn’t work with either one, everything needs to be smoked from scratch. What are the pros and cons of these technologies and the most important questions:
1. Where will it be faster?
2. What is preferable if in the future there will be integration into social networks and tablets?
3. If canvas, what framework would you recommend for such a strategy?

Thank you very much right away.

Answer 1

20,000 divs are architecture issues, not technology choices. Even if you switch to flash or canvas, it will not get rid of the problem of displaying such an array of data. You need to reduce the amount of data displayed on the client.

Answer 2

As a user I say, do it on Canvas, we don't need your flash!

Answer 3

Flash
0. As already mentioned above, the problem cannot be solved directly. Those. simply due to performance do not get out.
1. Easier to develop. At least some things can be done through animation. As a maximum classical OOP. This will make it easier to work with a large number of objects.
2. The vast majority of games in social networks are flash, which, as it were, hints.
3. About mobile devices. It will be much easier to port the game to AIR and distribute it as an application than to mess around with mobile browsers.

Answer 4

Canvas - will still work in any modern browser, even in mobile, even in devices from Apple.

Answer 5

In my experience, Flash will be faster, at least for now. But the speed of canvas is gradually improving. For example, in Chrome it already works very fast.
You can also greatly benefit canas performance by using WebGL where possible. Here is an interesting library that implements 2d API through 3d - WebGL2D

Answer 6

The comments above - the problem is in the logic of building a tree house, they say ... This is actually not so. Everything is well done, well done.
And to answer the question, if I were you, I would choose flash if you do not plan to make an application for iphone. For apple products html5 and canvas. And try to look at such a development tool as Construct 2 - this is a visual development environment for html5 logic, of course, it is not very convenient to write logic, but a good graphical representation.

Answer 7

Canvas of course.

Answer 8

I didn’t look at the links, but there is an assumption not to display the entire map in the DOM, but to display only the visible area, and this will clearly be less than 20k elements. An example is the same Yandex.maps of the first version, where fragments are loaded when they enter the visibility field and are deleted when they disappear from visibility.
Of course, this is conditional and the scope can be wider than the actual size of the visible field, but the point is not in choosing a platform, but in architecture, as mentioned above. Well, html5 will be easier to translate into mobile platforms

Answer 9

And you can use Unity3d and compile to Flash. You get a hardware accelerated flash, and 4000 triangles and 20-30 materials (or how many types of tiles do you have?) Even an ancient computer will crank

Answer 10

You should also abandon jQuery and use such a thing if you want to dramatically increase the speed of working with the DOM

Answer 11

webGL

Answer 12

It doesn’t necessarily go to something, you just need to break the map into sections, and insert the necessary sections, and not delete the visible ones.

Answer 13

I once wrote a similar one (well, relatively - there the map was static, and only “units” were separate objects), so I can advise you to somehow cache the map so that a relatively static large surface would be the same for the browser. You can aggregate hexes into large squares or hexes on the server and make tiles like on google maps. And yes, filter objects on the client by viewport, otherwise users or a large map will clog up the client's resources again. The client cache can be peeped in Googlemaps, although there seems to be nothing complicated there.
It is clear that you will have to bind mouse events somehow through coordinates, and make special effects one more layer. Sadly, each element in the form of a diva is convenient, but not viable.
You can do it the way it's done in flash - take raw data for all objects and draw them on the client, but flash is IMHO the old age. You can draw a full map on the canvas, but for really large maps, IMHO it's better to do it through tiles in a quarter-eighth viewport

Answer 14

If I had a choice, I would most likely choose Flash as a system originally created specifically for such tasks (yet when it comes to creating full-fledged ("rich") applications, I have a certain antipathy for HTML and related technologies, a real whose task is the layout of text documents).
But there is no choice for a long time, Flash has already been buried waist-deep, if not neck-deep in the ground - this is how strong market players, including Adobe itself, decided. So when "choosing" between standard HTML technologies and Flash, the answer is definitely the first one, unless your task is to quickly write an application that will only work under x86 Windows and will be relevant for a limited time.