Play-off: HTML5, Flash and Silverlight. Who is the last to die?

Eugene Akinshin

“Prediction is difficult—especially of the future”
/Mark Twain/

I noticed that people ask me with increasing frequency: «What to use to write our new on-line application: HTML5, Flash or Silverlight? » on what I invariably respond: «It is necessary to carry out the careful analysis of business requirements to your software in order to answer to this question» that certainly sounds better, than «who the hell knows», but has the same value.

Old kind days, when having written the application for Windows, you could be sure that 99 % of the solvent demand will be met, are irrevocably passing. Now, as in times when dinosaurs were vigorously running on the earth, before absolute domination of Microsoft on desktop, it is necessary to port applications to a set of incompatible platforms: Windows, MacOS, iOS, Android, Windows Phone, you name it. The thing that doesn’t represent a great problem if you create another primitive client for a social network, turns to huge amount of work when developing unpretentious casual game and becomes the real nightmare when it comes to the creation of corporate software. There are very few people who enjoy controlling identity of constantly changing business logic simultaneously implemented in different programming languages, never mind expenses for support of this zoo that strongly exceed cost of the monoplatform solution. In such situation, it is not surprising that uniform cross-platform development environment became some kind of the «sacred Graal» for the developers which searches cause, perhaps, more holy wars, than searches of original Graal by crusaders have caused.

One platform to rule them all?

Demand breeds supply – there is a serious struggle for domination over minds of web developers.

According to IT press, the obvious favorite in this race is HTML5. Is this opinion justified? Let’s temporarily forget that HTML was initially developed as a means of creation of hypertexts and doesn’t suit creation of the application interfaces, while javascript, though being one of the best languages for writing scenarios, is badly adapted to development and maintenance of the big applications, and refer to the facts.

And the facts are as follows:

Html develops too slowly. May be, occurrence of the primitive interface for drawing of the vector graphics (aka Canvas) in 2011 seems a real miracle to fans of this technology, but in real applications we want to use screens with multi-touch, webcam, microphone, printer, never mind new devices, such as GPS, accelerometer. The standard which will be accepted in 2020 will include none of this, and, taking in consideration current rates of development, we will get a modern 2011 platform not earlier than the beginning of 22th century.

Regardless of the amount of times serious men from various committees repeat a mantra: «standards, standards, standards», each browser on each platform continues to have its own opinion on how to correctly render html and execute java script. You are the real guru in web development and have achieved identical appearance and behavior in the complex application? Most likely, only to find out that performance of the same code significantly differs in different browsers. Have coped with it as well? Be ready to repeat this procedure at least once a month – as new versions of the browsers ruthlessly breaking compatibility are released with increasing frequency. And it seems to be infectious.

Considering the aforesaid, it is no wonder, that the best web applications created by corporations with huge budgets, look student’s hand-made frobs even in comparison with desktop software of the beginning of 90th, while demand for native solutions for smart phones grows in a geometrical progression.

Other applicant for superiority is Flash technology and at first sight it seems to be in the best form. But constant problems with security, instability of a plug-in, poor performance of the mobile version and Steve Jobs ready to do everything not to admit flash to his mobile platform, prevent wide penetration of this technology on the market of corporate solutions. Add relative imperfection of the programming language and development tools, and also the fact that flash is the closed platform maintained by a single vendor which creates classical «vendor lock» everyone is afraid of. Can Adobe cope with all these problems? May be.

Some absolutely stupid naive people, like me, believed in Silverlight. When creating Silverlight, Microsoft was able to consider and solve most of the technical problems of the competing technologies (it’s not so difficult if you create a product from scratch 15 years later than the competitors), and have constructed a really successful platform for web development. Silverlight offers advanced development tools and programming languages, there are no problems with compatibility, and sand-box provides complete security. However, the indefinite policy of Microsoft concerning this solution and refusal to port Silverlight to new mobile platforms, and also traditional mistrust of web developers to products of this company have taken the toll. Silverlight has strongly occupied the narrow niche in the sector of corporate development, but it has no chance for the world supremacy.

To complete the picture it‘s necessary to mention JavaFX, tell where to Java-applets have gone, to cry over the destiny of the cross-platform Java and.Net applications.

What’s the result? I should recognize that all attempts to pull a condom on the globe to create a completely cross-platform development environment for the last twenty years have failed. There are too many distinctions between the platforms: different processor architecture, different API of the operating system, non-comparable performance and volume of available resources, various forms-factors, periphery and, at last, ways of using devices.

What to do?

Is there a decision of this problem? Yes, and it is known from the moment the first computers appeared. Simply start the program on the server and use remote access from any computer.

Advantages of such approach are obvious:

  • We have complete control over the server, we can use any development tools, any equipment, any libraries, provide 100 % compatibility of all with everything, ideally optimize the solution.
  • Our intellectual property is completely protected. All application code is executed exclusively on the server – forget about pirates, forget about hackers, forget about fighters against copyright.
  • Thanks to relative simplicity of communication protocols, creation of a client part for all platforms doesn’t represent great difficulty.

Remote access is widely applied in the corporate environment for quite a long period, but hasn’t yet found use on the consumer market. And there are some reasons.

First of all, good network connection is necessary for work with the remote application. Do modern Internet channels provide it? Almost. Critical parameter is response time, not channel capacity. Unfortunately, 200-300 milliseconds typical for the modern Internet are perceived by the user as program “lag”. Is the situation going to improve in the future? Absolutely. Quality the Internet of channels constantly grows, and there are no doubts that in the nearest years this problem will be solved. Besides, fashionable tendency of transition to “cloud” servers allows choosing of the nearest data-center depending on a physical location of the user, that also considerably reduces response time.

Other important factor is the price of server resources. Currently, transition of all calculations to the server is not economically expedient for many applications. However, the price for computing resources constantly decreases and that day, when purchase of the server time from a hoster will be cheaper, than purchase of the powerful device, is not so far. Besides, distribution of cloud technologies, with their flexible allocation of resources, will allow accelerating this process.

And at last, there should be the standard protocol of interaction between client and server software. We recognize that the widespread protocols of terminal access based on pixel-by-pixel image transfer to the terminal, don’t address the needs of modern applications as they don’t allow to work with video, use smooth animation, involve 3d-accelerators, while modern developments, such as RemoteFX, offering all these abilities, are not yet so popular.

So, as soon as evolution of the Internet channels provides necessary communication quality, rent cost of the server equipment falls to comprehensible level and there is an industrial standard of the remote access protocol with support for 3d-graphics, animations and stream video, necessity in uniform client runtime for web applications will disappear, and it will be enough to supply all devices with the thin client of remote access.

Something of the kind.

P.S. In the meantime, we have released a new component for Silverlight. This component allows you to build-in unified designer for diagrams creation in any application.

July 5th, 2011

Leave a Comment