In many of my previous posts I've discussed the importance of mobile, and the company where I am employed as the lead software engineer; the users have shown us over the past couple of years that they prefer to visit our site on their mobile over their desktop.
It's clear to me that we need to not only understand that our users want a good mobile experience, we actually need to be proactive in supplying the best experience possible to keep up with users expectations, or the users will go where their expectations are met.
Libraries can be swapped out and replaced if they prove problematic. Frameworks on the other hand, tend to be a lot more difficult to swap, often requiring a rebuild of the app in question and inherently a lot bigger and under-utilised.
I’m concerned by the costs of frameworks on mobile, so I'll focus on frameworks and not libraries.
Your project code should functionally provide a feature your users interact with, Frameworks only provide developers a tool to start writing that code not the feature itself.
Good developers use frameworks, great developers understand how frameworks abstract the real vanilla functionality.
Frameworks are an inversion of control. They control the lifecycle of the app, and give you entry points where your code runs. You’re still responsible for the final code, but you’re not in control. One day you’re just coding, developing your app, and in the console you see a warning telling you that there’s been a deprecation. That often requires figuring out what the latest version of the framework is and what it needs you to do differently, and that may also mean refactoring projects. You have to take time out to learn any new or updated framework: what it means to write idiomatic code for that framework; its patterns, practices, and ways of doing things.
That's more control taken from you by Frameworks, you can't even focus on your app sporadically and those deadlines or stakeholders or clients are calling while you're upgrading, refactoring, and re-learning.
You could be creating features or fixing UX bugs with that valuable time wasted
But how to avoid frameworks effectively?
One of the most helpful Framework features is abstraction, which is commonly said to mitigate complexity. It does mitigate complexities that arise I admit, yet a lot of complex code I've seen is actually written to circumvent the strangle hold frameworks themselves impose on you. Frameworks aside though, complex code is inevitable and the key to handling complexity is in understanding the difference between abstracting and SoC. Look to design patterns rather than frameworks.
Abstraction is for simple, single purpose, reused functionality, it will allow you to be DRY. SoC can be misconstrued, put simply SoC can be DRY and it can be code duplication. Being DRY is not always best practice, and abstraction can be the downfall of a project.
Complex functionality should be respected, do not try to abstract it as abstractions are inherently complex due to imperative programming fundamentals and are an unnatural thought process for humans. Respect the complex functionality and do not attempt to make it reusable for the sake of one day it might be reused. Functional programming patterns are great tools for dealing with complexity as it allows a human mind to process concisely what is happening, the real challenge is first learning all of the possible patterns and you will be able to easily identify how to best tackle any coding problem you encounter with the right pattern.
The idea of a design pattern is an attempt to standardize what are already accepted best practices. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.
All of this is actually how the frameworks are written, yet these frameworks don't provide your product and users any features on their own, whereas you as a developer can cut out the framework entirely by employing the patterns yourself in your own code.
Instead of learning a framework, learn design patterns.
If we can achieve fast-booting, low-memory, smooth-executing frameworks with good ergonomics we’ll be onto a winner. Basically, the best framework can only be one that is available natively on the platform; I just wish one day the developers who toil at frameworks contribute back to the greater community by enhancing the open web itself.
Until then, for mobile at least, I’ll be sticking to the vanilla web platform.
Just remember, the best way to be the best developer is to learn the underlying platform and all of the design patterns, and hire those whom you know respect the language as you have come to by doing the same.