Framework and Libraries
You should prefer core-language solutions to small abstractions to small helper internal libraries to general libraries to frameworks
When you use a library, you are in charge of the flow of the application. You are choosing when and where to call the library.
When you use a framework, the framework is in charge of the flow. It provides some places for you to plug in your code, but it calls the code you plugged in as needed. You write code for the framework to be able to use it, you are beholden to the framework, to get it's benefits
NOTE: With any library,
be sure to understand it's pros and cons (esp around secruity and legal), does it meet cost benefit for usage
Does it fit in with your organisation, team, codebase, when used in production?
Is it well maintained, number of contributors, passing tests, good test coverage, usages in production code
Good documentation, good example tests, easy to follow source code
Should be able to follow code in library, esp during dubugging.
Need to rely on documentation, and if poor, then rely on stack overflow
test it
write poc (proof of concept), investigate using it
best to do this with similar libraries to make a choice between
try it out but be able to make it easy to remove if not working out
The only way it can be found as useful is in production
avoid having to build lots of hacks or engineer solutions to bugs or needed features which are not suited to library
Avoid having to have comments or readme/faqs to help user deal with problem
using a library, means adding new stuff to learn, new api etc.
This can lead to misuse, need to place checks and balances
automated tests to write to avoid issues
plugins for IDEs
extra time on code reviews/pairing needing to look out for these issues instead of focusing on business features or important techenical issues
more time debugging, having to go through library, or decomplied classes etc
This can be avoiding, practicing good design ie least astonishment, ease of use, fluent api, etc
Coupling problems, when a new version is out, then consumers will need to upgrade
but if there are breaking chagnes in the new version, this can lead to some consumers using different versions (esp with open source libraries)
Eventually they will need to move to new version
security updates, deprecation of functions
which means more work which is not of business value
Choosing
We often have two choices when implementing some logic. Either:
Build it ourselves
This involves a cost of time, maintaining
But in charge of fixing, being custom built
Get it from someone else
Which can entail:
Some one else builds it for you, thus it becomes custom to your needs, and likely improved upon or bug fixed quickly
Use something that is already out there, ie a library (private or open source), but beholden to the creator(s) to decide when to fix bugs or improve.
This is built with general user in mind, so may not fully meet your needs
When choosing a library or service to use, despite being free or paid, we must take it upon ourselves as engineers and for the well being of the business to evaluate it properly.
Areas to consider:
If the code is small, poorly implemented, not well tested, no maintained, few users (forks/clones/downloads) then should not use
If code has had issues in terms bugs, poor defaults, doing more than it should
If it brings in the world
If the license will cause problems
If compatibility with future upgrades may cause problems
Design choices - easy to use
There are ways of mitigating these issues, is too put libraries on edge of your applications, using dependency inversion, adapters, so that the may logic of the app is not tied to the library. The user of a library, should not be beholden to a library (or be very careful in what libraries you choose to couple/tie yourself to).
https://jaxenter.com/choose-right-java-library-159386.html
Differences
https://www.programcreek.com/2011/09/what-is-the-difference-between-a-java-library-and-a-framework/
https://medium.com/datafire-io/libraries-vs-frameworks-626cdde799a7
http://danielemargutti.com/2017/12/13/applications-vs-frameworks-vs-libraries/
https://www.tonymarston.net/php-mysql/what-is-a-framework.html
Principles
https://kukuruku.co/post/do-not-learn-frameworks-learn-the-architecture/
frameworkless
https://frameworkless.js.org/
https://dev.to/misomir/frameworkless-web-development-3n2h
https://github.com/frameworkless-movement/awesome-frameworkless
Libraries
https://www.oracle.com/corporate/features/library-in-java-best-practices.html
https://www.baeldung.com/design-a-user-friendly-java-library
framework coupling
https://dzone.com/articles/framework-coupling-revisited
Frameworks advantages
frameworks disadvantages
Frameworks can be seen as one of the hugest anti-patterns in software development.
They're hard to learn and this knowledge is generally useless
Where as learning fundamental tools, core computer science concepts, and programming techniques which are useful and timeless
The core stuff learned will help in being able to use frameworks and how it works
frameworks though can be a lot of magic
people use frameworks or latest shiny thing due to peer pressure, without thinking about the consequences, cost/benefit, is this the solution for the situatoin at hand
They limit your creativity
Frameworks make you dumb. Whenever you're faced with a problem you can't just invent a solution; you're limited by what the framework lets you do
You have to seek experts, waste your time and energy to find a solution to a problem you shouldn't have had in the first place if you hadn't used a framework
Spending time engineering a solution to get around a frameworks issue instead of business requirements
You can't let framework authors control what you can or can't do. You should be in total control over your product.
you can use clean architecture to invert dependencies on framework/libraries
They increase your project's complexity and dependencies
Complexity and dependencies are bad. You should keep both your project's complexity and dependencies at minimum
If not controlled will lead to dependency hell
There should be strict rules what you can and can't use in your project, and someone has to make that call.
Without rules you might save time at the beginning and sound cool using all the latest frameworks, but now your software is so complex that no one understands how or why it works
It's also become unmaintainable. You may not notice it in the first few months as things are moving along quickly, but as your project progresses, your team's productivity will drop because of all the complexity and dependencies. You'll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you're dead.
Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.
They go out of business and get abandoned.
you need to trust the authors of this framework
You have to learn the new frameworks again. It takes a lot of effort, energy and resources. You just spent all that time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.
All tooling that was created are useless
You have to maintain and upgrade your code to match the latest framework versions for no good reason.
If you wait too long between updates, frameworks have changed dramatically, and you have to spend days adjusting your code and learning the new interfaces. You don't need all the extra functionality the framework developers added. Most likely you don't need anything at all from the new version.
Framework developers can't stop evolving their projects for no good reason. Often software is just done. It does what it's supposed to do and doesn't need any changes ever again. You don't need the latest version of every software. Some of the best software was written 10 or 20 years ago. Use it!
Upgrading versions for no reason is another huge anti-pattern. If software works at version X, then it should stay at version X and should never be touched unless absolutely necessary.
Upgrading is hell
You have to search for help and ask others for advice when you're stuck.
When something goes wrong with the framework or you get stuck, you can't just come up with a solution because you're limited by what the framework lets you do. You have to ask for expert help, wait until someone helps you or pay an expert framework consultant.
If you keep your dependencies to bare minimum, then you're the expert and you can quickly get things done and come up with the solutions without ever asking for anyone's help or advice.
And you probably only need a small percentage of features that the framework offers anyway.
"Which frameworks shall we use?" is the wrong question to start you new project with. Start your project with an empty file and use programming and a few helper libraries and core tools to get it going.
http://tomasp.net/blog/2015/library-frameworks/
https://medium.com/@john_doherty/why-i-dont-like-javascript-frameworks-7714d1fd34b7
https://medium.com/@kevincennis/you-re-thinking-about-frameworks-the-wrong-way-83544a337a27
http://www.catonmat.net/blog/frameworks-dont-make-sense/
http://samatkinson.com/why-i-hate-spring/
http://tomasp.net/blog/2015/library-frameworks/
https://timperrett.com/2016/11/12/frameworks-are-fundimentally-broken/
Framework v library
https://dzone.com/articles/programming-without-a-framework
https://dzone.com/articles/discussion-recap-to-framework-or-not-to-framework
The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc. Why? I use JavaScript solely, and I agree with the author 100%. The frameworks solve a lot of problems, but by bundling those solutions together they introduce a new problem.
How do you organise the interaction of libraries?
This is what coding is. Asking this question over and over. You can't escape it. You can make a promise to yourself: "I'll just do it the Rails way" but that doesn't get you off the hook. Now you need to learn what the Rails way is. And that itself is never done. You will need to ask over and over "What is the Rails way?"
You can do it yourself but you will have to follow some sort of pattern to organise the code in order to make it easy to work with.
Again, that's is what coding is. Patterns. Which pattern do we need now? How about now? How about now? The Rails pattern only takes you so far. And for many problems it will steer you wrong. You can't avoid learning patterns and when to use them, it's part of your job.
What happens when another coder joins your project?
Part of why this is scary, is because if you use a framework that coder REALLY needs to understand the framework. The framework itself is a big domain of code that you generally don't want to have to debug, and you don't want to have to wonder how it works. You kind of need to know how it works before you start.
But idiomatic code is different. If I write a system in pure, idiomatic Java, with no framework, a new programmer doesn't have to understand any kind of underlying system. They don't need to understand a framework, because there is no framework. All of the code is right there in the repo. They can just go read it. They can place a debugger and walk step by step through the whole interaction, without ever leading their codebase.
Are you going to tell them the pattern you have already been using?
Yes, usually if they're new we pair program until they get a sense of the layout. But again, they don't need to learn the pattern in the same way that you need to learn the Rails routing pattern, or the Rails ActiveRecord pattern. You don't need to learn the pattern of a bespoke codebase, because you can just go read the code. There's not some separate system which is doing it's own thing in parallel to your application, there's just your application.
What if they dont follow it as expected or disagree with it?
Great! That's their job too. They should disagree with the architecture, find better ways of doing things, and talk about that with their coworkers.
Frameworks standardise this. Yes you might not always like certain aspects of the framework you're using but its the price you pay for not having a project full of developers who each have their own way of doing things and are constantly argueing over how to organise the codebase.
Sometimes that standardization is a worthwhile tradeoff for sure. If you need to get up and running quickly, and you want to start with a big team who already has some alignment, you definitely need some standards.
You also probably want a framework if you're building lots of apps that will mostly not be maintained. So, like special event apps for NFL playoffs, or marketing campaigns or something.
But if you're starting with a couple of developers and growing organically, and if you're trying to build a product that you will be actively adapting to your business needs for many years, a framework might get in your way in the long run.
Last updated