Back in my day, when only frameworks that existed were meant for pictures.
Early in the IT evolution, the two main development environments – Unix and Microsoft were evolving independently. Naturally, the need for some control was felt lest we end up with a “one or the other” kind of computing world too, already dealing with the polarized political world.
Early standardization efforts towards openness were mainly for two end goals – portability and interoperability. Quite simply, the applications should be able to talk to each other irrespective of their origin and if things got really uncomfortable you should be able to change your origin as well.
If an organization considered future portability as a worthy design consideration (who wouldn’t), standards like ANSI C, POSIX and SQL were offered, although the UI standardization had to wait for the web to fully take-off. If your application design operated within the constraints of these standards, you had a good chance to switching sides in future.
While the interoperability goal thrived (Thank God!), the portability goal was abandoned somewhere along the way. Perhaps people weren’t switching sides as often as they imagined. The shelf life of software was dropping, making clean restart an option and soon the only portability people now know was that of their mobile service provider.
This don’t-care-about-portability situation was exactly the primordial soup that was needed in which frameworks could take form, evolve and thrive. I have a bone to pick with the general idea of frameworks – at least in the context of what I have seen, which is frameworks like Spring, Angular and React – I assume the others are no different. The common idea of frameworks was to enforce certain discipline in programmers towards the use of key design principles. This is done through the use of “inversion of control” (aka “you don’t call us, we will call you” principle) where the framework owns the control flow and the application only provides business logic. A worthy principle in theory, but in practice I think they have been nothing but disaster. I will come to the mention of ZOAPI platform in a moment, and that it radically changes the landscape for the development of Web-services, but first more on why I think so lowly of the frameworks.
- Principle of portability in the framework world is thrown to the winds – so much so that new versions of the same framework are incompatible with the older versions. Even though portability has limited value in today’s tech environment, significant benefits need to be demonstrated for one to abandon it entirely.
- Even after being around for so long, they have done nothing to reduce the effort/time required in application development or even testing, while continuously raising the entry bar in terms of programmer skill and training.
- The frameworks add no real functional value to the application developer or the user. For example, the much touted two-way data binding of Angular was a convenience at best – not deserving of changing your religion for.
- The development environments keep getting heavier and demanding on the processing power, in just trying to keep pace with these frameworks.
The ZOAPI Web-Services platform is a product, represents a clean break and allows even non-programmers to build full-scale Web-services and web-service integration easily.
Author: Manoj Agarwal, Chief Architect – ZOAPI.
Do not forget to visit the website: https://zoapiio.com.
