(jargon, chiefly computing) Capable of or characterized by an adequate or excellent level of performance or efficiency. [quotations:] Ours is a performant network monitoring and systems monitoring tool.This software is more performant than its predecessor. Of or relating to performance — Wictionary
This definition of "performant", unofficial as it may be, is a fine starting point to try and identify its meaning, attributes and characteristics. Following is a break down of our main points of interest.
There's so much debate on coding syntax and benchmarking. Newcomers in programming and professional hype machines will be the first to draw their arms arguing about what is "best".
Paraphrasing the saying: "the best function is the one you never have to fire". There's no value in using the fastest algorithm if it's blocking the user experience. The feeling when an application responds the instant the action is initiated is invaluable, even if the process completes with some delay...
More important than the execution speed is the timing of the execution. Intelligence in the execution, sequence and even buffering of a function can make a slow process seem fast.
Architecting an application is not just popular pastime for developers of the pedantic kind, it is also the reason for a lot of the limitations applied to the users in production. Our job and responsibility is to push those limits the furthest possible without diverting from established best practices.
In that regard, modular programming is a tradition that encapsulates best practices in a reusable format. Beyond the obvious benefits from shortening development cycles there are other perks from its architecture, like readability and failsafe error control.
Probably the most important performance improvement that goes unsung is that it encourages parallel processing and that in turn allows the use of logic patterns in optimal formations. This is at the root of our subject matter. It wouldn't be an overstatement to say that modules put the "perform" in "performant".
So, at this point it's justified to wonder how does a "performant" app look? Does it have a lot of dependencies or does it rely on a lot of custom logic? Is it easy to read and manage or does it all look incomprehensible like machine code? Both and none at the same time, depending on what our priorities are. That may sound enigmatic, but let's try to analyze:
An app might be difficult to read and have a lot of custom code; it may be performant in execution but has no path for maintenance. On the other hand an app might have a lot of dependencies but be very easy to read, might be slower in execution but can cleverly hide it. The latter app has a better future because it can be maintained indefinitely. There are other variations of the above by making different arrangements...
On the issue of dependencies, there's a popular myth that a well-known framework will infuse an app with quality code and thus performance benefits. It's an unfortunate assumption that will always fail on its own. Tools won't make a developer smart; following trends doesn't make anyone cool. This tendency is understandable. Everyone needs guidance, especially in emerging technologies when little experience has entered the collective consciousness.
A better plan would probably be simply caring for the product, showing sincere commitment and patience. That should leave us with the structure we'll be most comfortable with in the long run. Being performant is a classic case of an overnight success, a long time in the making.
Just before we outlined how important responsive is. Strategies like progressive enhancement offer practical solutions to that end by incrementally presenting elements to the user they can interact with, while allowing the app to "breathe" as it consumes more logic cycles in the background to complete each request.
The word "performant" doesn't imply speed - it implies the impression of speed. The goal of the app is to be proactive and cater to common scenarios. That way we can minimize any possible latency and allow the user to enjoy a seamless experience.
Using common techniques like pre-fetching and caching can make an app seem more "alive". Again, this is on the same theme that showing a partial result instantly is better than showing a complete result in a short while.
What would performant be if not efficient. An attribute so popular it's at the tongue of every biz-dev; at the tip of the spear of every developer. We all want efficiency, even if we interpret it in different ways: being efficient in consumption, in resources, in transport, in maintenance...
However we define efficient, the performant app sits on the fine line between what offers the most cost-savings and what is academically the better solution. A good example of that balance is the relationship between client-side and server-side rendering. Either of them are less efficient on their own, but put together they complement and benefit each other, offering a better outcome.
The focus for efficiency is defined by our needs and by the application's footprint. Regardless, in most cases we want our app to be efficient both for the user and the developer. If we can achieve both we are truly on the right path to building a performant app.
Although "performant" is a made up word not available in the English dictionary yet, it is trying to describe a real concern for many developers, as they try to conceive and describe software that is optimal and communicate how to achieve performance improvements.
Being "performant" is not about hype or pretense, it's about the end-user experience. As such, it should not be used as a barrier for exclusivity and privilege but as a common goal all apps should be aiming at.