A burdensome choice
Building a project from scratch and choosing its technologies is a rare opportunity but brings with it a great responsibility. The choice will affect the company and its customers for many years to come. It can either allow you to evolve quickly with your environment, or shackle you to constraints, workarounds and outdated technology. Without careful consideration, a choice that appears to be good today might emerge as being a bad choice tomorrow and years of investment can be thrown away.
Choosing the right technology for your web application is like selecting a movie to watch on Netflix or picking up the right tea at a Mariage Frères store: you can’t try all of them but you wish you could select the best one! And the more choices you have, the more likely you will be concerned that you had not selected the best option: it is called the paradox of choice and has been described in 2004 by the American psychologist Barry Schwartz. Not only can an increased choice lead to anxiety and dissatisfaction, but it can also lead to indecision or analysis paralysis: this is illustrated by the paradox of the Buridan’s ass where a hungry and thirsty donkey placed midway between a stack of hay and a pail of water dies unable to choose one over the other. More recently, this Dilbert strip also exemplifies the issue.
The technology is not the only key factor
There is no need to worry however. Choosing the technology is only the first step. It’s what happens next that ultimately determines whether your choice was correct. Just remember that today’s requirements can evolve. Attempting to find the perfect fit does not necessarily protect you from future changes. In addition, do not forget that the technology is not “the alpha and omega” of a successful project. There are more important factors involved, such as the application design and all subsequent choices that the developers will make during the application lifespan.
ActiveUI Requirements
Listing our requirements for ActiveUI proved to be extremely helpful in narrowing down the choice of technology. Some of the items in the list can be seen below:
- Leverage specific ActivePivot features: to measure up to the backend, the interface needs to handle on-demand calculations, what-if analysis, edit and write back of the data source and incoming real-time dataset. This requires an extremely interactive UI where each component can be updated by multiple sources
- No specific server required: there should be no server side code to run and any application server should be able to serve the static files
- Highly customizable code: not only do the APIs need to provide a great flexibility through configuration, but part of the code describing the view needs to be customizable
- A web library: from past experience, we know that it is almost impossible to build a “one size fits all” ready-to-use interface. For each customer, there are unique and detailed requirements. For this reason we need to develop a library of configurable components, with which customers are able to either build a tailored application, or integrate our widgets with existing web applications, or use a standalone interface that we would provide (built with that same library!)
- High performance: we need to be able to display large server datasets with high volumes of updates through the browser. This means that great care must be taken in communicating with the server, interacting with the DOM and consuming memory and CPU. Considering that the backend has been polished to deliver the result at lightning speed, wouldn’t it be pointless to render in two minutes a dataset that took just half a second to compute at the server side?
- Browser compatibility: IE10 minimum or a recent version of Chrome and Firefox since that is what is required to use WebSocket
Confidence-building Criteria
Additionally, some criteria can assist you in finding the right technology and at the same time give more confidence in the results. Examples are:
- How popular is it on GitHub?
- How many related questions & answers are there on StackOverflow?
- How many job offers require this technology as a pre-requisite?
- How many resumes claim that their applicant is knowledgeable about the technology?
- Does the company have developers with knowledge of the technology internally?
- How often do they release?
- How mature is the framework?
- Is it used in production?
- How big is the community behind it?
- Is there a large company backing or using that technology?
- Is it well documented?
- How easy it is to test?
- How has the technology been assessed/reviewed by influential people? …
Naturally, as each company’s requirements are specific, it may be acceptable that the answers to one or more of the questions listed above are not entirely favorable. Also, there is no guarantee that a framework matching these criteria will not be discontinued one day. History tells us that even a framework backed by a large company can be deprecated at some point. Well-known examples of this happening are Microsoft Silverlight, Adobe Flash or Yahoo YUI.
The outcome
This prompted us to choose a pure client-side framework and we ended up comparing React with Angular. To find out why we selected React as opposed to Angular, read the full story in the next article!
atoti Product Owner Julien Bec is the Product owner of atoti. Before taking this position, he has worked in R&D at ActiveViam for 9 years in Paris and New York.
Julien Bec
atoti Product Owner Julien Bec is the Product owner of atoti. Before taking this position, he has worked in R&D at ActiveViam for 9 years in Paris and New York.
You like this post ? Please share it on your socials
Innovative data analytics that empower financial services firms to be ready for the unexpected.
Company
Learn more
Copyright © 2019 | ActiveViam