Essential Algorithms Solutions has a dedicated research team that remains abreast of any and all innovations related to software development so that the absolute most state-of-the-art technology is available to clients. Our development team also takes fresh or recent ideas and improves them on both a functionality and stability level so that the latest technology and tools can be utilised with the same reliability and stability as older previous technology.

The type and level of innovation used in a given software project will vary on a case-by-case basis, and is also left up to individual clients. Some examples of how E.A.S. has leveraged innovative technology in lieu of older standards are as follows:

  • HTML5 in lieu of Flash. Flash was known for years as the leader in animation technology, allowing for high-quality and impressive content to be delivered to end users. However, in recent years, certain popular devices such as tablets and smart phones lack Flash content support and are thus unable to display or use any Flash videos. E.A.S. was one of the first adopters of the various HTML5 visual-related standards, including native video embedding, native sound playback support, canvas drawings and modelling, and sprite-based animations. Unlike Flash, HTML5 content is platform agnostic and can be used on nearly any modern device.
  • WebSockets in lieu of Ajax. AJAX was (and arguably, continues to be) the premier method of dynamic content loading. E.A.S. continues to use Ajax in certain cases where it is still the appropriate choice. There are other cases where Ajax is actually not the best tool for the job. For example, many times when real-time data or statistics are being delivered to a client, Ajax is no longer the best technology to use. It requires long-polling (maintaining a connection with the server until new content is available, unless a timeout period is reached in which case a new connection is brokered and held open) or time-delayed fetching (such as re-requesting from a WebService automatically every 5 seconds via JavaScript.) Both of these cases can be slower and also wasteful compared to real-time data pushing. For true real-time data push, E.A.S. leverages WebSockets technology to maintain a true push relationship between the server and the device.
  • Caching in lieu of database access. Some applications, particularly web-based ones, involve a great deal of database access for "fetching" of data. While it is true that certain data is ever-changing and thus not reasonably cacheable, a surprisingly large amount of data can be cached. In some cases, it's possible to remove all end-user DB requests entirely, and direct them towards a caching technology. Since most caching implementations are horizontally scalable, this greatly increases the scalability of the application and detaches the application's theoretical load limit from the database's load capabilities. Meanwhile, most real-time data changes that traditionally would have to be theoretically "pulled" from a database can actually be pushed to the cache engines (in order to update them) and also to any connected devices (in order to ensure each user has the latest data) using the WebSockets layer described above.
  • Client-side management of the presentation layer. Many long-standing web technologies, such as the PHP scripting language, operate on the premise that the server prepares all HTML for display and the client is responsible for displaying it. If, for example, you have a table of data with headers that will sort the data when clicked, each time said link is clicked a request is initiated with the server, the server prepares the data, and data is returned to the client for display. When practical, E.A.S. will shift most or all of the presentation responsibilities onto the device. In the example given above, the server would have an API that provides the raw data, and the client device would use JavaScript to instantly sort or filter the data without needing any further requests to the server. This makes the solution much more "snappy" and also limits server and database load. On a more advanced level, the entire look and feel of the UI can be customized using drag-and-drop customizations. In that scenario, the server would be completely agnostic as to which device is connecting to it (as each device has its own customized UI) and returns the same data -- possibly via cache -- and each device displays it in a unique way given its own client-side scripting.