I’ve had a few interesting conversations recently highlighting & confirming my perspective on software development frameworks.
1.) Do you know Zend?
I was asked if I know Symphony and my response was “sort of”.
They responded (in a snarky tone) “well, you really should know Symphony & Zend because we have a massive job upgrading from Zend to Symphony since Zend is well past end-of-life”.
2.) Do you know Angular2?
We desperately need to upgrade from the original Angular2 because it’s no longer supported and not compatible with the current versions.
3.) Do you know Laravel?
We insist all devs work in Laravel rather than PHP because we know & trust Laravel.
4.) Laravel is a great ORM
To that I say “I really like the idea of ORMs and automating the job of DBA (database administrator), but how does your ORM handle noSQL?”.
Turns out Laravel can’t handle the new (5yr old) MariaDB JSON functions. These “new” functions make MariaDB a really cool noSQL store. PostgreSQL has had JSON functions and noSQL support for 12+ years, not sure how Laravel handles that.
Frameworks can be extremely valuable
Anything that can be done in a framework can be done in the vanilla, base-level programming language since frameworks are built on the existing functionality of the programming language.
As an example, there’s a great NPM package called Axios for handling API queries. It is entirely possible to make an API query in vanilla JavaScript, but it’d take a lot of code and engineering to do it as quickly and smoothly as Axios does it. In this example React+Axios saves time and improves code quality.
One of values of a framework.
Frameworks as an additional dependency
Those statements/conversations highlights an opinion I’ve had all along; a framework is just another dependency and it can become obsolete just like a base-level programming language.
Here’s an example, a security vulnerability is found in your programming language and a bug-fix is released. Unfortunately the framework you build on doesn’t work with the bug-fixed release so you are forced to remain on the vulnerable version until the framework is updated. Alternatively, you must go through and cut out the framework from your software project.
One of the risks of all dependencies is an unfixed vulnerability or abandoned project.
Risk v. Reward
All software dependencies carry some risk, frameworks sometimes provide value. It’s a matter of weighing the risk versus reward.
Frameworks as a Crutch
When I hear statements like “we require devs to work in X framework” its likely a false crutch. Sound, anti-fragile software requires doing a risk assessment and code review of every dependency. It also requires managing that dependency, reviewing every update for malicious changes or hacks, and constant monitoring for vulnerabilities or abandonment. Relying on a framework to improve security and/or code quality without reviewing the framework for security and code quality would be a false crutch.
Side note, there have been a few examples of open source projects getting hacked and losing control of their Git repository. As a result the code security is immediately questionable. If automatic updates are applied you can get into a whole heap of trouble. Or, if a Git repository hack has gone unnoticed you could be blindly installing malicious code or a back-door.
Frameworks as a Limitation
If the reason you cannot leverage recent language upgrades and features, like noSQL, is simply because your framework doesn’t support it then it may be time to question the value of the framework (or leverage features and functionality on-top-of or in-addition-to what your framework provides).
As a simple example, there’s nothing in Laravel or any other framework, forcing you to specifically use a given database or limitations. You can use Laravel but make direct database queries, it just requires sound management and SDLC.
To Boldly Go or Blindly Go?
Software and technology is by definition innovative. If you are boldly innovating where no one has gone before; that’s great. If you are blindly going where you have never gone before; that’s dangerous.
Like any piece of the Software Development Life Cycle (SDLC) and project management, decisions need to be sound, educated, well-thought-out, and regularly reviewed.
End of the Day
End of the day, I think its easier and less risky to use front-end frameworks in web apps There’s significantly less risk of a back-doors or malicious code if the framework only ever runs in the users browser. These frameworks can also often speed development and reduce browser inconsistencies. Whereas on the server where data is stored, passwords are stored, and processing happens the risk can be compounded.
There’s also many different types & levels of frameworks. Pythons FastAPI is a great framework that does 1 thing and does it really well. PHPs Laravel framework on the other hand tries to handle input sensitization, database connections, database queries, request routing, etc., etc., etc.