When framework becomes too complicated and incurs high learning curve, it's no longer a "framework".
If I'm not mistaken, software development framework came from the idea of Rapid Application Development (RAD). It has the following major goals:
- Encapsulate and enforce best practices through great design patterns to improve software application quality.
- To speed up application development and meet project deadline without compromising great quality.
- To allow developers to become more business focus, sparing more times and resources to meet business and functional requirements.
But recently, although more and more frameworks have become largely available, some have almost forgotten our goals as stated above -- they've almost defeated the main purpose of being a "framework". I do not want to mention their name, but some have truly overdone. They've become more and more complicated and incurred extremely high learning curve. Just the framework itself relies on too many dependencies, and just the dependencies alone require separate installation and complex configurations. Being natively strong in the language itself is no longer enough for the developers to quickly get started and put the framework into use. Worse thing is, this issue has been ignored by the community and continue to branch out to a much complex evolution.
I hope all of us can start to rethink how our software development frameworks can be redone and further simplified without deviating from our fundamental goals here. To assist this achievement, I have the following ideas:
- Always look back the accumulated complexity to avoid unconscious evolution of the framework.
- Always take into consideration of the required learning curve and compare the time needed for it to be put into use, with and without it. Think of this: What if someone can use a native way to complete the same module in almost the same amount of time than learning the framework, setting up the framework, troubleshooting the setup, trying out the framework, and implementing the framework? What if before being capable of making the framework work for them, they've already gotten the work done in a native OOP way? Can you measure the productivity and efficiency between these two?
- With so much of dependencies, how portable the application will be by using your framework?
- What will the Cost of Ownership be if your framework is used by the software company? How easy it is to hire the developers who are proficient with your framework? If they hire a junior programmer, how long is needed for a junior to pick up your framework?
- Can we take the best backend and frontend framework of the same language and improve them with simplicity rather than add more complexity or keep on creating new competing frameworks that serve the same purpose? Isn't that the term "Open Source" serving this purpose?
- Can we identify the prerequisite and optional implementations and simplify both of them so that the learning curve for the prerequisites can be reduced, and the optional ones can be hidden for later needs? Let's take AngularJS as an example: They let the prerequisite with less complex configurations to serve the fundamental purpose, e.g. SPA routing and two-way databinding, while letting the advanced purpose like Directives, Factories etc. as optional implementations. Honestly, right until today, my MTN Web Store App is still running fine and meet all my requirements without a single use of custom directive and factory.
Frameworks should hide the complexity but not to demand for vast amount of learning time, setup time, and high cost of ownership. With open source, you still can study the complexity behind a particular framework if you want to, and this is why the node_modules folders and Git are for. As for the overhead, now we have ES6 Import, just that the webpack that takes advantage of it for tree-shaking, again, is too difficult to learn and configure.
I do not want to talk about the quality of the framework here because those framework creators are always good at it. What they are not good at or lack of are being conscious about the depth of the tunnel that they've dug through and unaware of the potential collapse behind them -- their framework may become more costly than they think should otherwise be reduced.
If you really want me to name a few that I think is truly a good framework, I would say Google Firebase. Just the Firebase Authentication and Cloud Functions alone save the developer tremendous amount of time and workload -- you don't even have to deal with JWT and cookies, no separate setup of database just to store the user credentials, no creation of DBContext class, no running of migration command line, nothing -- A truly Concern Separation from the user roles and other business rules! With the Firestore onsnapshot, I can build a real-time chatting app in less than a day even though I was new to it -- these are called FRAMEWORKS. But sadly, and unfortunately, very few software vendors in Malaysia in particular, know how to value Firebase, this makes me feel a little bit disappointed.